As a software development manager, the git branching strategy you choose will be a crucial component of your development workflow. Here, we’ll take a quick look at five git branching strategies starting with the easiest and generally proceed to the most complex. This follows the advice of Mike Kaufman, a Microsoft Regional Director on this matter, “…start small and add complexity only if you need it.”
He also gives a nod to Conway’s Law in finding a git branching strategy that fits how your team works. Conway’s Law basically asserts that organizations tend to design systems that mirror their organizational structure – and how they communicate. Factors that can influence the branching strategy best for your team include:
- Whether your project requires Continuous Integration/Delivery or a need to support different environments and release versions.
- The size, experience, and maturity of your development team.
- The relative ease of conducting merges and contending with other issues of administrative overhead.
GitHub Flow
Table of Contents
The GitHub Flow is the simplest branching strategy as it has only two types of branches. The first is a continuously deployable master branch or trunk. All work is done on short-lived feature branches. Once completed, reviewed, and fully tested, feature branches are merged back into the master branch.
When to use it? It’s ideal for small development teams and startups, as well as Continuous Delivery style projects. It’s not good for projects that must support multiple environments or release versions.
GitHub Flow Diagram
GitHub Flow and Trunk-Based Development are very similar – compare the image above with the one below. XXX
Trunk-Based Development (TBD) Diagram
The TBD strategy is very similar to the GitHub Flow as reflected in the two images above. The main difference with TBD is that instead of releasing from a feature branch, they are merged back into the master branch and then released to reduce the chances of a regression. In most respects, TBD is fit for the same type of projects as GitHub Flow and is ideal for Continuous Integration and Delivery.
GitLab Flow
When multiple environments come into play, as with mobile apps, or when working on a SaaS project, things get more complex. The GitLab Flow still tries to keep it simple but adds environment and release branches. It’s a middle-of-the-road strategy that’s adaptable for nearly any type of software project on a Continuous Integration/Delivery or Release basis. While startups starting with simpler GitHub or TBD strategies may naturally gravitate to the GitLab Flow as their team and project requirements grow. Additional guidance can be found in GitLab Flow documentation.
GitFlow
In following the order of complexity of the five main Git branching strategies, we should discuss OneFlow next. But, to better understand how OneFlow works, it’s better to cover GitFlow first. It’s also appropriate to point out that this is where everything started. GitFlow was one of the first formally defined Git branching strategies, and it became a sort of de-facto industry standard. Vincent Driessen first presented it in 2010.
And… this is what it looks like:
GitFlow has two long-lived main branches (master and develop) with three support branches (release, feature, hotfix). It is the most complex branching strategy and as one might suspect, best suited to large organizations through smaller development teams have used it, too.
Also Read: 9 Best Chrome Extensions for Developers in 2021
Everything about it is hard and heavy and creates a history that is hard to follow. It’s a rigidly controlled workflow that may be necessary for teams with many junior or inexperienced developers. Senior developers control what is committed and that can create bottlenecks. This strategy is well-suited for managing different releases and environments, but it is not suited to Continuous Integration/Delivery.
The OneFlow Branching Strategy
OneFlow aims to keep all of the functionality of the GitFlow branching strategy while dramatically simplifying it with one long-lived branch. The one factor it requires, like GitFlow, is that every new product release must be based on the previous one. It doesn’t work if you need to maintain multiple release versions. It is also not well-suited for Continuous Integration/Delivery projects, though it can work for them with some adjustments.
The OneFlow approach makes considerable use of rebasing, and for that reason, which some developers may find controversial. It does, however, keep a fairly clean and easy to read history. The use of OneFlow is likely best reserved for mature and experienced development teams. OneFlow was created by Adam Ruka who is an experienced developer for Amazon. OneFlow’s not necessarily the “one branching strategy” to rule them all but it can provide larger development teams the agility GitFlow doesn’t.
In Summary
Getting back to Mike Kaufman’s advice, keep it simple. Examine the project requirements, your team, and capabilities. As a general rule, startup projects can probably default to the GitHub or TBD branching strategies unless their software will need to be supported on multiple platforms. Similarly, the GitLab strategy should be a good fit for nearly every organization that’s not already heavily rooted in its ways – as enterprises often tend to be.
