GIT Workflow that works

The Git Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.

Git is ideally suited for projects that have a scheduled release cycle. This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature, Task or Bug Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Of course, you also get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration.

Getting Started

Git Workflow dictates what kind of branches to set up and how to merge them together. We will touch on the purposes of the branches below.

Develop and Master Branches

Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It’s also convenient to tag all commits in the master branch with a version number.

The first step is to complement the default master with a develop branch. A simple way to do this is for one developer to create an empty develop branch locally and push it to the server:

Feature, Task and Bug Branches

Each new Feature, Task and Bug should reside in its own branch (e.g bugfix or Task/1.0.0/developername/Task or Bug id; feature/ developer name /feature name), which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, Feature, Task and Bug branches use release branch as their parent branch. When a Feature, Task and Bug is complete, it gets into develop using PR. Feature, Task and Bug branch should never interact directly with master.

Finishing a Feature, Task and Bug branch

When you’re done with the development work on the Feature, Task or Bug the next step is to merge the worked branch into develop using PR

Release Branches

Once predetermined release date is approaching, you merged all the Features, Tasks and Bugs into release candidate branch which we will create after every production release. This we will call next release version which should be named as 1.0.x. Creating this branch starts the next release cycle, so no new features can be added after this point — only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it’s ready to ship, the release branch gets merged into master and tagged with a version number. After merging to master, we will create next release branch from master.( e.g. release/1.0.X)

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development (e.g., it’s easy to say, “This week we’re preparing for version 2.0.0,” and to actually see it in the structure of the repository).

Hotfix Branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they’re based on their own release. As soon as the fix is complete, it should be merged into its release branch and develop (using PR), and release branch should be merged into master, master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master. A hotfix branch can be created using the following methods:

The overall flow of Git is:

• Create a git branch by default it will be called `master`
• A `develop` branch is created from master
• First `release` branch is created from master
• Create release branch from master and name It with release version. (e.g release/1.0.0)
• While working on Feature, Task or Bug create the branch from the release branch like this bugfix/releaseVserion/Developer/ Task , bug-Number (e.g bugfix/1.0.0/devlopername/Task-1770, feature/devlopername /Feature name)
• Once the Feature, Task or Bug is fixed and unit test performed. Push the branch to remote.
• Once Branch is pushed create the Pull Request (PR). While creating the PR base branch should be developed. Invite other developers or Team Lead to review the code
• After code is reviewed and approved by the Team Lead. PR should be merged. (PR be automatically merged to develop branch
• Feature branches are created from develop
• When a feature is complete. Create the PR with develop as base branch.
• When we are ready for UAT, merge all the approved ticket from QA into release branch and then merge the release branch into master
• If an issue in master is detected a hotfix branch is created from its release branch
• Once the hotfix is complete create PR with develop as base branch. Once PR approve merge the hotfix branch into in its parent branch and to master