Git Branching Strategies

Some quick notes on different Git Branching strategies.

I am covering the 3 main strategies, and discussing them in increasing order of complexity: GitHub Flow, GitLab Flow and Git Flow.

Note there are many other (frankly better) resources out there on this topic, including

• Branching Strategy (cloudbees.com)
• 4 branching workflows for Git (medium.com)
• Branching patterns (martinfowler.com)

 

GitHub Flow

GitHub Flow is by far the simplest of the branching strategies discussed here. You start at the master branch, creating a branch for new work (e.g. new features or bug fixes) and merging it to the master branch when done. 

(source)

That’s it. It is particularly well suited to CICD environments, where you continually deploy to production from master. 

One thing to note though is that you can deploy from your feature branch too, not just master e.g., deploying your feature branch to a QA environment for further testing before merging to master.

 

GitLab Flow

GitLab flow is a little more complicated and supports environment branches.

While GitHub Flow’s simplicity is its main selling point and having a master branch that you can always deploy can often work well, you may need to support multiple different environments at the same time. In those situations, consider GitLab flow.

In the the following diagram, there is a staging environment (master), a pre-production environment, and a production environment.

(source: gitlab.com)

Note that this approach incorporates feature branches too, typically before environment branches. So for example, you might create a feature branch from master, and merge it in to master when done. It is after that, when you start thinking about what to deploy to what environments that you start creating environment specific release branches.

 

Git Flow

Git Flow is the most complex of the branching strategies discussed here. It seems rigid, there are a lot of steps required to get code in to production, and is perhaps best suited to projects that require multiple versions to be live and supported simultaneously (e.g. on multiple customer sites). As a result, I don’t think it is particularly well suited to the CICD model. That being said, it is perhaps the most well known git branching strategy, and no doubt works well where a higher level of control and oversight is needed. 

Git Flow was created by Vincent Driessen back in 2010. An overview of it can be see here:

(the original pdf by Vincent Driessen can be found here at nvie.com)

 

There is a master branch, for production-ready code, and develop branch, for the latest code being readied for the next release, akin to an integration branch. In addition, there are a number of other supported branches including:

• feature branches
• release branches
• hotfix branches
  
  

From the original discussion “Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets.”.

So, again, complicated, but a typical flow might be

feature -> develop -> release -> master -> hotfix 

See more at Gitflow Workflow (atlassian.com).

In a recent note from the original Git flow author himself, Driessen pointed out that Git flow was built to “support multiple versions of your software in the wild” and that “if your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow)”. 

Tags: branching, git, gitflow, github, githubflow, gitlabflow