2021’s Most Implemented Branching Strategy

• Share on Facebook
• Share on LinkedIn
• Share on X

With today’s enhanced focus on remote development, it is only logical that we look at 2021’s most implemented branching strategy. Branching is necessary to ensure a project’s codebase is protected as well as provide the means to implement multiple changes at once. Things are straightforward when developing with a small team. However, complications arise when too many cooks are in the kitchen.

Why Teams Use a Branching Strategy

If you develop on a team of more than one person, you likely run into the scenario when both of you are developing on the same component. If not the same, possibly on dependencies required for proper interoperability. You and your teammates need a way to collaborate the changes you make in code to ensure things will play nicely, together.

CI/CD processes have created opportunities for those implementing branching strategies to take advantage of the stability aspects. Proper branching does not just enable safe feature creation or bug-fixes. The right kind of branching strategy promotes innovation.

At times, developers need the opportunity to try new methods in their code. This means implementing new versions of libraries used to help the program operate smoothly and possibly enable new features. Using branching allows for those engineers to test scenarios in a local setting, push it to the team’s code repository, and let the CI/CD process run to see how their changes affect the product.

Throughout this process, the master branch is safely maintained while the changes make it to production. Any feature branches, bug fixes, or dependency references used in the release are merged back to the master branch and the cycle repeats!

Feature Branching Strategy

The methodology a team uses for tasking is definitely relevant to the branching strategy they choose. Many project management packages offer integration with code repositories. By using these connections, developers can initiate a new feature branch that links directly back to the change.

This is also called task branching, as it allows for multiple tasks to be completed by various members of the team in isolation. Developers can then pull from each other’s commits to ensure changes made are not detrimental to the project or component. This merging of commits eventually culminates into a shippable release candidate. However, the fact that merging on a constant basis is one of the reasons other branching strategies are considered.

A product of this and other types of branching strategies is the ability to track changes directly to the initial request. This is critical in today’s world where a chain of responsibility is in place for many industries. Auditing ability for changes made that affect data security or compliance standards must exist for some companies to maintain certain certifications.

Release Branching Strategy

An extension of feature branching; the teams that choose release branching often create their own individual branches for code changes. The changes are then able to be cycled through the CI system of their pipeline to check for compile and even compliance issues. The key difference between release and feature branching is how releases themselves are handled.

Rather than merging backwards or horizontally to implement other developers’ changes, release branching allows for feature branches that will merge forward into a versioned “release.” This fix-forward approach is a key aspect of Agile development of web applications. It also allows for larger stories to be conceived and completed by engineers.

Trunk-Based Development

In contrast, Trunk-based development depends on a large amount of merges to be completed throughout the workday. It is not as easy to implement aspects of the CI/CD process such as automated testing, code coverage, and continuous delivery.

Because of the large amount of merges necessary, developers tend to work on smaller changes to the code. Working with these smaller pieces of code allows more intense testing and experimentation on each change. This additional scrutiny is necessary to keep the code base free of errors.

Some Teams Just “Git” It!

There are plenty of source control systems on the market to support a branching strategy. None of them have taken the majority share of software engineering teams like Git. It is no surprise that the number of developers choosing Git has been increasing year after year.

As a repository, Git provides a large number of features that can get complex. Especially when compared to other source control systems like Mercurial. These methods are designed to get work done in a way that aligns with teams that use Agile Software Development for tasking.

Another reason for Git’s popularity is the cloud offerings like GitHub and GitLab. Not only do they conform to the Git repository standard, but they also empower DevOps automation with a gambit of additional features.

Going With the Flow

Two methods work very well with these branching strategies and are more relevant in today’s world of software development than most methods. Gitflow Workflow and GiHub flow are based on the idea of using Git feature branching to modify and deploy the code without actually touching the “master” branch. Teams who have successfully implemented this type of workflow see significant gains in velocity.

Gitflow Workflow

Considered a bit complicated for many of today’s projects, Gitflow Workflow has seen strong usage since 2010. By basing changes and bug fixes on branches created from master, teams are afforded many liberties in their development. Releases are identified and put through separate processes to compile, test, and deploy the changes.

By not committing changes to master prior to deployment, mistakes and logic errors are not introduced at a time when other development may be starting as part of an Agile cycle. This protection of the codebase is a huge reason why teams choose a branching strategy to begin with.

An additional benefit of Gitflow is the organization aspect of the changes needed. The feature branches created by the developer work alongside named branches that help coordinate other release types. This helps support merging and other aspects of branch management in a manner that makes sense.

• master — A representation of the codebase that is currently in production whose commits have gone through the entire flow and merged after post-release verification.
• develop — The culmination of all feature branches that have been merged into the branch. Often used to run automated testing and releases to development resources through CI/CD pipelines.
• features — Each change meant for inclusion in the next release are completed in feature branches that correlate with project tasking.
• hotfix — Similar to feature branching, but can be based off of master. Allows for fixes to continue to support production while not affecting current development. Any changes can be pulled into active feature branches and/or back to master to ensure the issue isn’t re-introduced.
• release — As it sounds, this branch is used as the final culmination of the feature branches slated for release. This branch would be a candidate for production and changes merged back into master after verification of a successful release.

GitHub Workflow

The GitHub workflow contrasts Gitflow workflow in one major way. Releases are meant to be done on a continual basis. It is good for teams able to make modifications and review those changes often prior to making it to production.

Rather than using a named branch for a release, GitHub workflow assumes that what is in the master branch is what should be deployed. Developers still utilize feature branching to base their changes off of master, but depend on pull requests and code reviews to gate what goes into production.

This flow is good for continuous deployment and the fix-forward approach. It doesn’t depend as much on a sprint cycle to end in order for development to start on other portions of the software. It also promotes more interactivity with the team via peer-reviews on code.

A Parting Thought

These branching strategies have solidified their place in software development. Which branching strategy you and your team use is dependent on factors specific to your product and release process. In most cases, development teams go with release branching to support changes that align with their tasking system and to support different phases of the release cycle.

Others enjoy the increase in velocity they gain from simple feature branching. In each case, the main codebase is protected while developers can work diligently on their individual portions of code. Thanks to CI/CD ability on these feature branches, new features and out-of-the-box approaches to bug fixes can be developed in a way that allows for a substantial amount of peer-review without slowing down the process.

We see less and less usage of workflows that involve developing directly from the trunk or master branch. This can be especially cumbersome to manage vs other methods that have seen great success in software development. As we move forward, those that are adopting more SaaS implementations of Git and integrate with tasking will likely move away from this method in favor of a branching model.