Git and other version control systems give software developers the power to track, manage, and organize their code.
In modern software development, speed and agility are crucial when it comes to developing and releasing software. However, when you have a large team of developers working simultaneously, branching and merging code can become messy fast.
Therefore, teams need to have a process in place to implement multiple changes at once. This is where having an efficient branching strategy becomes a priority for these teams.
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:
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:
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.
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.
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.
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.
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.
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.
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:
No rights reserved by the author.