GIT Branching Strategies in 2022

Git branching

Using a version control system, software development teams use branching strategies when writing, merging, and deploying code. In essence, it is a set of rules that developers can follow when interacting with a shared codebase.

Keeping repositories organized prevents errors in the application and the merge hell when multiple developers work simultaneously and add their changes at the same time. Merge conflicts of this nature would eventually deter developers from shipping code quickly, thus preventing the creation and maintenance of an efficient DevOps process.

By adhering to a branching strategy, developers will be able to work together without stepping on each other’s lines of code. Creating a clear process when modifying source control allows teams to work in parallel to achieve faster releases and fewer conflicts.

The term “branch” refers to independent lines of code that branch off the master branch, allowing developers to work independently before merging their changes back in.

Why you need a branching strategy

As mentioned above, having a branching strategy is necessary to avoid conflicts when merging and to allow for the easier integration of changes into the master trunk.

A branching strategy aims to:

• Enhance productivity by ensuring proper coordination among developers
• Enable parallel development
• Help organize a series of planned, structured releases
• Map a clear path when making changes to software through to production
• Maintain a bug-free code where developers can quickly fix issues and get these changes back to production without disrupting the development workflow

What are some common Git branching strategies?

The biggest advantage of a Git branch is that it’s ‘lightweight’, meaning that data consists of a series of snapshots so with every commit you make, Git takes a picture of what your files look like at that moment and stores a reference to that snapshot. This means that these branches aren’t just copies of the file system, but simply a pointer to the latest commit. This also adds a new layer of flexibility, in which you can take any route to define your own strategy. Some of the most battle-tested and mainstream ways to do that are exhibited here:

GitFlow

Considered to be a bit complicated and advanced for many of today’s projects, GitFlow enables parallel development where developers can work separately from the master branch on features where a feature branch is created from the master branch.

Afterwards, when changes are complete, the developer merges these changes back to the master branch for release.

Alongside the main branches are supporting branches including feature, release, and hotfix. These branches have a finite lifespan and strict rules regarding their use.

The feature branch branches from and merges to develop. It’s used for a specific feature and merged back when finished.

Release branches branch from develop and are merged back into both develop and master. They are created when the develop branch is nearly ready for release and used to finalize everything and fix minor issues. When the code is ready for release, it is merged to master.

Hotfix branches are for problems or urgent bugs that need to be fixed in the release code. They branch from master and are merged back to master when finished, and also merged with the develop branch.

Pros

• Protects the production code.
• Allows the main branch to remain stable for release while developers work on separate branches.
• The various types of branches make it easier for developers to organize their work.
• Ideal when handling multiple versions of the production code.
• The systematic development process allows for efficient testing.

Cons

• Development cycle could be slowed down.
• It is not an efficient way for teams to implement continuous integration and delivery.
• As more branches are added, they may become difficult to manage as developers merge their changes from the development branch to the main.
• It would become increasingly difficult to figure out where an issue is exactly as developers are lost in a sea of commits.

GitHub Flow

It is a simpler alternative to GitFlow ideal for smaller teams as they don’t need to manage multiple versions. Unlike GitFlow, this model doesn’t have release branches. You start off with the main branch then developers create branches, feature branches that stem directly from the master, to isolate their work which are then merged back into main. The feature branch is then deleted.

The main idea behind this model is keeping the main code in a constant deployable state and hence can support continuous integration and continuous delivery processes.

Pros

• It’s one of the most simple strategies.
• It allows for Continuous Delivery and Continuous Integration.
• Works great for small teams and web applications.

Cons

• This strategy is unable to support multiple versions of code in production at the same time.
• The lack of dedicated development branches makes GitHub flow more susceptible to bugs in production.
• The master branch can become cluttered more easily as it serves as both a production and development branch.
• As you scale up, though, it becomes challenging to manage the many pull requests.
• With larger teams, many developers are working on their own feature branches and, on merge them back, they can step on each other’s toes.
• There’s also the need to test and deploy from branches rather than from main, which may not suit all teams.

GitLab Flow

It’s a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking.

While similar to the GitHub flow branch strategy, the main differentiator is the addition of environment branches — i.e. production and pre-production — or release branches, depending on the situation.

Pros

• GitLab flow is more organized and structured than the GitHub flow branch strategy.
• GitLab flow can allow for Continuous Delivery and versioned releases.
• It works great for small teams and web applications.
• It offers propers isolation between environments, allowing developers to maintain several versions of software in different environments.
• This works well if your team consists primarily of senior developers.
• It is perfect if you are working on your minimum viable product.

Cons

• When working with junior developers, you should tightly control their work.
• It’s not the most structured Git branching strategy, which can lead to messy collaboration.
• Its flexibility means you have to carefully define how you’ll use it.
• Requires good communication and team collaboration on agreements about the proposed structure.

Trunk-based development

A branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime.

Trunk-Based Development is a key enabler of Continuous Integration and by extension Continuous Delivery. When individuals on a team are committing their changes to the trunk multiple times a day, it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to the trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.

Pros

• It paves the way for continuous integration as the trunk is kept constantly updated.
• Developers are able to see what other developers are doing without having to create branches.
• Best suitable for small teams.
• Very fast pace because there is very little, if any, overhead.

Cons

• Team maturity and seasoned developers are a must with this approach.
• The team must be very skilled and cautious because everything goes directly to the trunk.
• Usually, it requires feature flags to help decoupling deployment from release.
• This strategy is unable to support multiple versions of code in production at the same time.

Scaled Trunk-Based Development

TBD has another trick up its sleeve: Scaled Trunk-Based Development. In order to operate at scale, this branching model uses short-lived feature branches with a life span of a few days (maximum) before merging to the trunk, which is deployable at all times.

Work in progress should be kept to a minimum, not only to avoid merging problems with long-lived feature branches, but also to make up for easier and faster code reviews.

Code reviews will guarantee only quality code is merged to the trunk and will allow for very early defect detection.

Pros

• Solves many issues of the trunk-based strategy.
• People who practice the GitHub-flow branching model will feel that this is quite similar.
• Parallel development is supported.
• Quality is ensured with simple code reviews.

Cons

• This strategy is unable to support multiple versions of code in production at the same time.
• Short-lived feature branches are used for code-review and build checking (CI), but not artifact creation or publication.

Release Flow

Is a trunk-based development approach that utilizes branches off the master trunk for specific topics as opposed to other trunk-based developments that continuously deploy to the trunk. The naming convention of topics means there is also less confusion with the term feature in a common product backlog.

As merging is difficult, engineers are encouraged to commit early and avoid long-running topic branches that could become stale and increasingly difficult to merge back. Pull requests are used to merge back to the master branch.

In some sort of way, it’s a variation of the Scaled Trunk-Based Development strategy. The main difference between both of them is that in Release Flow you have the ability to send maintenance changes to a release branch.

Pros

• By extension, the same as Scaled Trunk-Base Development
• Allows maintenance of multiple versions or releases.

Cons

• Short-lived feature branches, or topics, are used for code-review and build checking (CI), but not artifact creation or publication.
• Cherry-picking changes to production increase the possibility of injecting unexpected changes into master branch or releases.
• Adding maintenable release branches adds a new level of complexity to development and CI/CD tooling.How to choose the best branching strategy for your project

After the previous review of the currently available strategies, we can conclude there’s not a silver bullet to handle any project. This table probably can help you to take a decision about which could fit you the best:

References

• A review of Git branching strategies https://www.learncsdesign.com/a-review-of-git-branching-strategies/
• A successful Git branching model https://nvie.com/posts/a-successful-git-branching-model/
• What Are the Best Git Branching Strategies https://www.flagship.io/git-branching-strategies/
• What is the best Git branch strategy? https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy
• Git Branching Strategies, Explained https://rewind.com/blog/git-branching-strategies-explained/
• GitHub Flow: The best way to use Git and GitHub https://githubflow.github.io/
• Git(Hub) Flow, Trunk Based Development, and Code reviews https://reviewpad.com/blog/github-flow-trunk-based-development-and-code-reviews/
• Introduction to GitLab Flow https://docs.gitlab.com/ee/topics/gitlab_flow.html
• Trunk Based Development: Introduction https://trunkbaseddevelopment.com/
• Feature Flags: what they are and how to use them https://www.flagship.io/feature-flags/
• Trunk-based Development https://www.flagship.io/glossary/trunk-based-development/
• Release Flow: How We Do Branching on the VSTS Team https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/
• Adopt a Git branching strategy https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops

No rights reserved by the author.