Now a days, GIT repositories have been very common and most of the developers are aware of what branching strategy is being used by their current projects. We all know that Git branching strategies affect a lot of things in the project. Among other things, it affects how much effort would be spent for operational activities. Hence, it is also important to understand what are available branching strategies.

In this first article of the GIT branching strategies series, we are going to discuss about Gitflow workflow, a branching strategy. This strategy has been discussed already , a lot of times, in different articles. There is a comprehensive information about this at atlassian. I am just going to provide some summary and my views about this strategy.

Gitflow Workflow Basics

This is considered as one of the complex Git workflows. It was first published and made popular by Vincent Driessen. Please refer this hyperlink to know about this workflow in detail. The following paragraph briefly explains the workflow.

There are multiple branches involved in the workflow:

• master branch, which is supposed to contain the main version of the code. In many recent codebases, the name “main” is used instead of “master“.
• develop branch, which is created from master branch. It is used for current development work.
• feature branch, which are created from develop for each backlog item. The development work for the backlog item happens in the feature branch. After the development work is done, this branch is merged to develop and the feature branch itself is deleted.
• release branches, which are created from develop branch. After each release is done, the release branch must be merged to develop as well as master branch.
• hotfix branch, can be created if any bug is found in the deployed application. In that case, the hotfix branch can be created from either the master branch. Once the fix is tested, the hotfix branch can be merged to master and develop to ensure that the fix is available in all the branches.

Comparing lifetime of different branches

Feature branch has the shortest lifetime in the above diagram. It is created for a specific purpose (or backlog litem) and as soon as the work is done, it is merged to develop and deleted.

The master (or main) branch contains the version which is deployed on the production. It is never deleted (obvious reasons). Similarly develop branch contains the code which is being developed, but not yet deployed. It is also long running branch and it is also never deleted.

The release branch is a short lived branch. It is created from develop and it stays there until the product is being tested. Once testing is done, the release branch can be merged to master (or main). And the actual release to production can happen from there.

If some bugs are found in release branch, then there can be various ways in which it can be handled.

• Some teams may prefer to delete the release branch and create a new release branch from develop. This is simplest approach if the architecture allows it.
• Some teams prefer to create release-fix branch from release branch. Once the release fix is tested, it is merged to release branch as well as in develop branch and then release fix branch is deleted.

Hotfix branches are also short lived and they are merged back to their parent branch, which is master branch and then they are deleted as soon as hotfix is tested.

Pros and Cons

The advantage here is development can happen in parallel with release. It is because the code under development is in develop, and it is separated from the code being released (or already released).

One of the main disadvantage of this branching strategy is – operational complexity. It may be difficult sometimes for developers to identify where the bug fix should be merged and how many different pull requests should be created. The complexity and confusion may slow down development and release cycles.

Now a days, teams are adopting shift-left and DevOps practices. As per atlassian documentation,

Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. 

Have you been using this branching strategy ? What are your opinions about it ? Let me know your thoughts.