Choosing the best Git Branching Strategy for your team helps to deliver value to your production environment quickly and with a high degree of confidence. Generally, the best advice we can offer is to start simple. Don’t over-optimize your git branching strategy before you have something in your workflow that needs improvement.
If you find yourself as the only developer on a project, using a branching strategy that is less-than-the-simplest-tool-for-the-job is likely to be [premature optimization]. A single dev working on code should be able to get a single task into production within one business day from the time they start working on it. Yes, the code needs testing, so are including that time in our metric of “deliver value within one business day.” Tasks need to be small enough to be shipped in one day for this to be achievable.
The three primary strategies range from simple to complex in the following order: GitHub Flow, GitLab Flow, and Git Flow.
Start with the simplest thing that works.
GitHub Flow is a vastly simplified workflow compared to the process that Git Flow recommends. GitHub Flow is usually best for small teams that don’t need to manage several different environments or versions simultaneously.
GitHub Flow is trivially simple. You start from the
master branch, checking out a new branch to do your work. When you’re ready for your work to be reviewed and merged, open a pull request to
Even if you’re a solo developer on a project, we still recommend you go through the process of opening a pull request, as it serves as a record of changes submitted. The work should be tested (on its feature branch), and when it is considered ready for deployment, the code is merged to
master and deployed with due haste.
GitLab Flow is the newest popular branching strategy. It’s great for the case where you have multiple different environments that you need to support. In GitLab Flow,
master is still your base branch, and the code is branched from
master when you are working on features. Additional branches are release-purposed for different environments.
Example: Perhaps you have an iOS project, so you can’t control when your production releases are made (due to Apple’s review process). In this case, you’d cut a release branch at the time you want to deploy it, and employ some versioning strategy that makes sense for your team.
Work can continue regardless of changes from the appropriate release branch and cherry-pick those changes back into
master. This workflow minimizes [drift] as much as you can, considering that you can’t control production releases.
It’s also useful if you need to deploy a series of changes to a
staging environment. You’d cut the
staging branch from
master until the QA process is complete.
Advantages of GitLab Flow include the workflow still being simple.
Master is your base branch, and [you shouldn’t merge untested code to your base branch]. If there’s a problem with a release, you can handle the changes in the appropriate branch, and promulgate those changes back to
Git Flow, the original article from 2010 proposed that
master should be your production branch and that you should set the base branch to
development to avoid confusion. While there’s nothing inherently terrible about this, due to the nature of changing the defaults, it does come along with some cognitive load for the team to consider at all times.
In our experience, Git Flow encourages [drift between environments], since development is by definition not equal to production. We’ve seen Git Flow abused such that broken code is merged to
development and is allowed to make roost there for weeks before deployment.
Advantages to Git Flow are a highly rigid process. If your paranoia level is high for a good reason, Git Flow does provide some added protection. Compared with the other branching strategies, Git Flow increases the number of hoops that developers need to jump through in order to release code to production. If you have a rigid QA process and infrequent releases, Git Flow may be right for you.