Release Strategies x Git Branching

In this article, I would like to talk about how Git's branching strategies out there help us improve the release management process in the modern Software Development Life Cycle. Without further ado, let’s get started! 🤞

In the changing field of software development, Git has completely transformed the way teams handle and collaborate on code in global projects. It provides a version control system and oversight that revolutionizes the process.

One of Git’s standout features is its branching mechanism, which allows developers to diverge from the code base and experiment with features or bug fixes in a separate environment without affecting the stable production version. This capability goes beyond being a technicality; it has become a strategic tool in managing releases. Branching empowers teams to work on aspects of a project simultaneously making it easier to develop features, fix bugs, and conduct experiments independently. As a result, it shortens the development cycle. Improves software quality. Strategies like Git Flow, GitHub Flow, and GitLab Flow are examples of how branching in Git combines innovation with strategic vision. They demonstrate how software engineering tools and methodologies continuously adapt to meet industry needs.

What exactly is Git branching?

In the world of Git, a branch symbolizes a collection of code alterations that have deviated from the code base. Imagine it as a dimension where developers can freely experiment, develop, and make changes to the code without affecting the stable version of the software. It’s similar to an author working on versions of a chapter, in a novel each version explores plot twists while still originating from the same underlying story.

The main purpose of branches in Git is to separate and manage development efforts. This separation is important for reasons. Firstly it allows multiple features or fixes to be worked on simultaneously. For example, while one team member focuses on developing a feature (like a payment module for an app) in a ‘feature’ branch another can address a bug in a separate ‘bugfix’ branch. Both these branches originate from the source (the ‘main’ branch). Are kept separate ensuring that progress, on one, doesn’t interfere with the other.

Furthermore, branches play a role in enabling work, which greatly boosts productivity and efficiency. They allow teams to tackle aspects of a project simultaneously avoiding bottlenecks that can arise when everyone is working on the code base. Imagine a situation where there’s a bug that demands attention while the development of a new feature is still ongoing. By utilizing branching a developer can quickly create a separate ‘hotfix’ branch to address the bug while the rest of the team continues their work on another branch dedicated to feature development. This parallel approach ensures that critical fixes and regular development can progress without interfering with one another.

Essentially Git branching embodies the idea of “divide and conquer” in software development. It enables teams to separate their work into parts resulting in a structured, effective, and accurate development process. This approach ensures that the integration of code changes is handled systematically and strategically.

Alright, now that we have a good idea of what git branching is, let’s talk about different git branching strategies out there for us to use!

Core Git Branching Strategies

Git Flow

This is one of the most used Git branching strategies. The development process begins by establishing branches for each feature. These individual branches are later combined with the integration branch, followed by the release branch, for fine-tuning and ultimately merged into the main branch, for production deployment. If any fixes are required they are directly merged into the branch as hotfixes with an approval for the pull request. Then reintegrated with the development branch.

Image courtesy: Vincent Driessen’s Gitflow

While the above image describes how the overall process happens, let’s try to dive into different branches and their responsibilities.

Develop and Master/Main Branches

• The master and develop branches are the starting points for any project. They are very important and should be protected against accidental deletion until the project is better defined.
• Direct merges from develop to master are not permitted and develop branch features should be merged on the master branch over a release branch
• Only authorized leads or project owners should be given the responsibility to merge changes from other branches
• The master branch is a highly stable branch that is always production-ready and contains the last release version of source code in production.
• The develop branch is derived from the Master branch, the development branch serves as a branch for integrating different features planned for an upcoming release. This branch may or may not be as stable as the main branch. It is where developers collaborate and merge feature branches.

Feature branches

• Any new feature development needs to be conducted within a feature branch
• Merges back to the develop branch after a feature is complete
• After the merge is completed, the feature branch should be deleted
• The conventional naming of this branch starts with “feature/{TICKET_ID}/{SHORT_NAME}”.

Release branches

• This also derives from the development branch but is used during releases for QA, Staging, Performance, and Production.
• Any releases of developed features will conducted within a release branch
• QA, Perf, and Staging deployments should be done from the release branch
• Identified bugs need to be fixed in the same release branch and merged back to develop branch
• After the release is approved to deploy to the production, the release branch should merge with to master branch with a release tag
• Once the merge is done, the release branch should be deleted.
• The conventional naming of this branch starts with “release/{RELEASE_VERSION}

Bugfix branches

• This derives from the main branch and is used to fix a bug in the Dev and QA environments that were identified by developers or QEs.
• Bugfix branches are used to fix any bugs reported in Development and QA environments
• After the bugs are fixed in the bugfix branch, the bugfix branch should be merged to release branches.
• Once the merge is done bugfix branch should be deleted
• The conventional naming of this branch starts with “bugfix/{TICKET_ID}/{SHORT_NAME}”.

Hotfix branches

• This derives from the main branch and is used to fix a bug in the production branch that was identified after a release.
• Hotfix branches are used to fix any production bugs
• After the bugs are fixed in the hotfix branch, the hotfix branch should be merged into the master and develop branches.
• Once the merge is done hotfix branch should be deleted
• The conventional naming of this branch starts with “hotfix/{TICKET_ID}/{SHORT_NAME}”.

However, like any powerful tool, it comes with its own set of advantages and challenges. Let’s delve into the pros and cons of Gitflow strategy to unravel the full spectrum.

Pros and Cons of GitFlow

• The framework provides a structured system that clearly outlines the roles and responsibilities of each team. It is particularly effective for projects that involve developments.
• Ideal for projects that have environmental differences. i.e Staging is slightly different than Development
• However, it could potentially be too complex for projects and may not be suitable for paced release cycles.

GitHub Flow

Developers typically work on their feature branches. Once they finish their work and go through a review process they merge their changes back into the master branch. The main/master branch is consistently maintained in a state.

Image courtesy: Alex Hyett’s Gitflow and GitHub flow

This is a branching strategy introduced by the GitHub. But that does not mean you should be using GitHub to use this branching strategy. Let’s talk about its branches.

Master/Main branch

• The main branch contains the production code that can be deployed.

Feature branches

• Derived from the master/main branch to work on features or fixes.
• Post-feature development, it is merged with the main/master branch after the review.

Pros and Cons of GitHub Flow

• This approach is highly efficient which makes it a great fit, for integration and delivery purposes. Moreover, it proves beneficial for teams that are aiming for smoother release cycles.
• Aims for Agile principles, hence it is a fast and streamlined branching strategy with short production cycles and frequent releases.
• On the other hand, when dealing with production versions it might not be the choice due to the increased probability of encountering bugs in the primary system.

GitLab Flow

This is a branching strategy introduced by GitLab.

GitLab Flow is a simpler alternative to GitFlow and combines feature driven development and feature branches with issue tracking. With GitLab Flow, all features and fixes go to the main branch while enabling production and stable branches. GitLab Flow includes a set of best practices and guidelines to ensure software development teams follow a smooth process to ship features collaboratively. — GitLab

Now that we know in software development, new features are created in branches known as feature branches. These changes are then combined with the branch. Furthermore, there are also environment branches that handle code specific to stages of the release process. This helps to ensure that everything aligns smoothly with Continuous Integration/Continuous Deployment (CI/CD) pipelines.

Image courtesy: Git Workflows by Programster

Master/Main branch

• The main/master branch contains production-ready code

Environment Branches

• Uses branches for environments, i.e. staging, pre-production, etc.

Feature Branches

• Each feature or fix has its branch

Pros and Cons of GitLab Flow

• It offers a balance between an approach and simplicity making it suitable for environments that have stages.
• It is more complex than GitHub Flow and requires managing branches.

Trunk-based Development

This is a new branching strategy most of the tech giants use in the modern day. Mostly goes with mono-repos.

In Trunk Based Development the primary focus revolves around maintaining the trunk as the hub of development. Developers create feature branches for tasks and frequently merge them back into the trunk sometimes multiple times a day. This approach ensures that the trunk is always in a state for release. Continuous Integration (CI) plays a role in this process by running automated tests on each commit to the trunk ensuring its stability.

When it comes to releasing, some teams may choose to create a release branch, from the trunk as a step. This branch is used for preparations before going. Hotfixes are handled similarly with branches created from a tag on either the trunk or release branch. Then promptly merged back to prevent any divergence.

Image courtesy: Trunk-based development — Optimizely

Master/Main branch

• The main and core code repository where all modifications are swiftly integrated

Short-Lived Feature Branches

• Feature branches are made from the code to address features or fixes. These branches usually have a lifespan often lasting no more than a day or two to prevent divergence from the code base

Release candidate branches

• Before deploying to production, it is practice to have release branches, for staging releases.

Hotfix branches

• To address pressing issues create branches from the code base or designated release versions.

Pros and Cons of Trunk-based development

• It encourages code integration and simplifies the process of merging code branches.
• This approach is particularly beneficial, for teams that prioritize iterations and frequent releases.
• It also aids in the identification and resolution of conflicts and bugs thanks to the merging and testing practices.

Image courtesy: Christina @ wocintechchat.com on Unsplash

However, it’s important to note that Trunk Based Development requires a commitment to automated testing and continuous integration. It may not be the choice for teams or projects that involve developing large complex features over extended periods. This is because it can result in disruptions to the code base.

Additionally maintaining stability and deployment ability of the trunk at all times necessitates a disciplined approach to coding and testing.

In an example scenario using Git Flow, imagine there’s a large-scale software project where multiple teams are simultaneously working on features. One team is responsible for developing an authentication feature. To avoid any interference with work in the ‘develop’ branch they create a separate ‘feature’ branch for this feature. Once they finish developing and testing it they merge it back into the ‘develop’ branch for integration testing. After that, it goes through checks in the ‘release’ branch before being merged into the ‘main’ branch for deployment. This systematic approach helps ensure stability and clarity throughout the release process.

On the other hand, it considers another example using GitHub Flow. Suppose it has a web application that requires updates and quick iterations. In this case, developers directly work on their own ‘feature’ branches that are created from the ‘main’ branch itself. Once they complete their changes and undergo code review and testing these changes are merged back into the ‘main’ branch, which’s always ready for deployment at any given time. This approach is particularly suitable, for teams aiming to achieve iterations and continuous delivery. This example of GitLab Flow has an enterprise application that follows a staged deployment approach. The development process takes place in feature branches, which are later merged into the ‘main’ branch. To ensure transitions during deployment stages separate branches, like ‘staging’ are used to manage the code. This aligns with a CI/CD pipeline. Allows for better control over the release process while still keeping things simple.

The Right Strategy for the Team

Image courtesy: DISRUPTIVO on Unsplash

Choosing the Git branching strategy depends on important factors. Firstly take into account the size of the team; smaller teams may find it easier to manage their workflow using the simplicity of GitHub Flow while larger teams could benefit from the approach provided by Git Flow. The complexity of the project is also an aspect to consider; if the project involves interdependent features, Git Flow or GitLab Flow might be more suitable due to their comprehensive structure. Additionally, deployment frequency is another factor to consider for those who require continuous deployment the streamlined process offered by GitHub Flow can be advantageous.

As an example of a startup that is working on a web application and frequently needs to make updates. In this case, using GitHub Flow would be beneficial as it allows for iterations and continuous delivery. On the other hand, if it considers an enterprise, with a complex software ecosystem it might prefer using Trunk-based or Git Flow. These methodologies provide an approach to managing development streams and release stages. It’s important to adapt these strategies based on the team’s workflow communication patterns and project requirements to improve efficiency and clarity, throughout the development process.

Best Practices in Release Management with Git

In the realm of Git-based release management, it is crucial to prioritize the stability of the production branch. This involves implementing strategies that ensure hotfixes and emergency changes are thoroughly tested before being merged. The integration of Continuous Integration/Continuous Delivery (CI/CD) pipelines plays a role in simplifying the release process, automating testing, and facilitating deployments. Regardless of the branching strategy employed, having a testing and Quality Assurance (QA) framework is essential. For example in Git Flow feature branches must undergo testing before being merged into the develop branch. On the other hand in GitHub Flow, every change made in a feature branch needs to be ready for production, after review highlighting the significance of an efficient and comprehensive testing system.

Advanced Tips and Common Pitfalls

Understanding the intricacies of Git involves being mindful of challenges and utilizing techniques. One particular hurdle, often encountered when branching is referred to as “Merge hell.” However, this can be mitigated by syncing with the branch and establishing clear guidelines for merging. To effectively manage feature branches it is important to clean up branches and adhere to well-defined naming conventions to prevent confusion or clutter.

Additionally ensuring committed practices through code reviews and automated testing is crucial in avoiding mistakes during release management. These measures help guarantee that every merge into the production branch is smooth and free from errors.

Conclusion

Having a defined approach to releasing software using Git branching is crucial for managing software development processes. It helps to streamline workflows, enhance stability, and improve efficiency throughout the release cycle. However, it’s essential to understand that there isn’t a solution that fits all scenarios. The strategies should be. Continuously refined based on factors, like team size, project requirements, and real-world experiences. By embracing adaptability and learning from each release it can establish a more efficient development process that caters to the challenges of the projects.

References

• Jacobsen, D., Kleinmen, R. and Longley, H., 2018, May. Managing the SMW as a git Branch. In Proc. Cray Users’ Group Technical Conference (CUG).
• Teixeira, J.A. and Karsten, H., 2019. Managing to release early, often, and on time in the OpenStack software ecosystem. Journal of Internet Services and Applications, 10, pp.1–22.
• Loeliger, J. and McCullough, M., 2012. Version Control with Git: Powerful tools and techniques for collaborative software development. “O’Reilly Media, Inc.”.