A review of Git branching strategies
This article is originally published at https://www.learncsdesign.com
Software development and release require speed and agility.
Branching and merging code can quickly become complicated when a large team of developers is working simultaneously. To implement multiple changes simultaneously, teams need a process in place. Having an efficient branching strategy becomes a priority for these teams in this situation.
Branches provide teams with a separate workspace for developing features. Usually, these branches are merged back into a master branch upon completion. It makes it easier to fix mistakes if features (and bugs and bug fixes) are kept apart from one another. In other words, branches protect the mainline of code, so any changes made to one branch will not affect other developers.
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.
We will explore the pros and cons of some of the branching strategies used by teams in order to organize their workflow.
Need for branching strategy
- Enhance developer productivity by ensuring proper coordination
- Ensure parallel development
- Organize a series of planned, structured releases
- Establish a clear path for software changes through production
- Ensure that developers are able to fix bugs quickly and get them back into production without disrupting their workflow
Git branching strategies
These are some common Git branching strategies.
GitFlow
The following branches make up this branching strategy:
- Master
- Develop
- Feature- The development of new features created off the “develop” branch
- Release- Preparing a new production release; usually branching from the develop branch and merging back into both the develop and master branches
- Hotfix- Similar to release branches, hotfix branches arise from bugs discovered and must be fixed; they allow developers to continue working on their own changes on the development branch while the bug is being fixed.
As far as the main and develop branches are concerned, they have an infinite lifetime, whereas the rest are considered supporting branches designed to facilitate parallel development among developers, and are usually short-lived.
GitFlow pros and cons
- In this strategy, parallel development protects the production code and allows the main branch to remain stable for release while developers work on separate branches.
- Due to GitFlow’s complexity, the development and release cycles could be slowed down. So, GitFlow is not an efficient way for teams to implement continuous integration and delivery.
GitHub Flow
Smaller teams may benefit from GitHub Flow since they don’t need to manage multiple versions.
This strategy does not have release branches like GitFlow. The main branch is created first, then developers create feature branches to isolate their work, which is then merged back into the main branch. After that, the feature branch is deleted.
Continuous integration and continuous delivery are made possible by keeping the master code in a deployable state.
GitHub Flow pros and cons
- In Github Flow, branching is streamlined and short, and releases are frequent and fast.
- As you test and automate changes on one branch, there is no development branch, allowing for continuous deployments.
- When maintaining a single production version, this strategy is ideal for small teams and web applications.
- This strategy is more vulnerable to bugs, resulting in an unstable production code if branches are not properly tested before merging with master-release preparation and bug fixes are done on this branch.
GitLab Flow
As an alternative to GitFlow, GitLab Flow combines feature-driven development and feature branching with issue tracking.
GitFlow allows developers to create a develop branch and make it the default, whereas GitLab Flow works straight from the main branch.
You can use GitLab Flow when you want to maintain multiple environments and when you want to have a staging environment separate from the production environment. You can merge back into the production branch when the main branch is ready for deployment.
In this way, developers can maintain different versions of software in different environments while maintaining proper isolation between them.
GitLab Flow development pros and cons
- It is perfect if you are working on your minimum viable product.
- This works well if your team consists primarily of senior developers.
- When working with junior developers, you should tightly control their work. Their skills will be improved and potential bugs will be found more quickly if they submit strict pull requests. In that case, this strategy will not work.
Trunk-based Development
In trunk-based development, the changes are integrated into a shared trunk every day, thereby avoiding the need for branches. The shared trunk should be ready for release at any time.
This strategy emphasizes making smaller changes more frequently, thus limiting long-lasting branches and preventing merge conflicts as all developers work on the same branch. Developers commit directly into the trunk without using branches.
Trunk-based development pros and cons
- Continuous integration is possible with trunk-based development since the trunk is constantly updated.
- By making commits directly into the trunk, developers are able to see what other developers are doing without having to create branches.
- A more stable release can also be achieved by keeping the shared trunk in a constant releasable state with continuous work being integrated into it.
In summary, there is no such thing as a perfect strategy. This should be evaluated on a case-by-case basis depending on your team and the nature and complexity of your project.
If you like the post, don’t forget to clap. If you’d like to connect, you can find me on LinkedIn.
I have written more detailed posts on Git that you might find interesting.
