The Benefits of Using a Feature-Based Branching Strategy

TLDR;

Using feature-based branching strategy will help you avoid git hell, and has the following benefits:

• Easier collaboration: Each feature has its own dedicated branch, allowing multiple team members to work independently on different features at the same time.
• Fewer merge conflicts: Short-lived feature branches contain code for a specific feature, reducing the chance of merge conflicts when merging into the main codebase.
• Faster deployments: Features can be deployed as they are completed, since each feature is developed and tested in its own dedicated branch before being merged into the main codebase.
• Better visibility: Allows team members to easily see which features are being developed and the progress of each feature, improving project planning and resource allocation.

What is a Git Branching Strategy?

A git branching strategy is a set of guidelines and practices to follow when working with branches in a git repository. Git branches are used to separate different streams of development within a codebase, allowing team members to work on new features or bug fixes without disrupting the main codebase.

There are many different branching strategies to choose from. The right strategy will depend on the needs of the project and the team. Some common branching strategies include:

• Feature branching: Separate branches for each new feature being developed
• Release branching: Single branches are created for each release; these contain multiple features
• Trunk-based development: Working directly in the main branch

You should only consider trunk-based development if you have a very senior team, a mature product and lots of automation set up.

Why to Avoid a Release-Based Branching Strategy?

Release branches can only be merged and released to the end users after all of the features merged into it are stable. The drawback with this approach is, if you have a bug with one of the features, then the whole release branch cannot be merged or released. This leads to delays, slower speed to market and friction between the product development team and stakeholders.

What is a Feature-Based Branching Strategy?

A feature-based branching strategy involves creating a separate branch for each new feature being developed. These branches should be short-lived; being merged into the main branch as soon as development and QA is complete.

Why Use a Feature-Based Branching Strategy?

Here are a few reasons why a feature-based branching strategy may be a better fit for your team:

• Easier Collaboration: With a feature-based branching strategy, it’s easier for multiple team members to work on different features at the same time. This is because each feature has its own dedicated branch, which allows team members to work independently without worrying about conflicts with other features.

• Less Merge Conflicts: Because feature branches are short-lived and only contain code for a specific feature, there is less chance of merge conflicts when it comes time to merge the feature into the main codebase.

• Faster Deployments: With a feature-based branching strategy, it’s easier to deploy new features as they are completed. This is because each feature is developed and tested in its own dedicated branch before being merged into the main codebase.

• Better Visibility: A feature-based branching strategy allows team members to easily see which features are being developed and the progress of each feature. This can help with project planning and resource allocation.

How to Use a Feature-Based Branching Strategy?

If you have a feature which isn’t dependant on any other feature the branching process is very simple:

Image created using Mermaid

In the example above a single branch is created from main, and after a few commits and a pull request the feature is merged back into main and can be released 🎉

How to Implement a Complex Feature-Based Branching Strategy?

The example below shows how a feature-based branching strategy can be used with a collection of inter-dependant features, which must be released together:

Image created using Mermaid

Here the feature branch acts as a parent to house all of the dependant “child” features. The child branches are code reviewed and merged back into the feature branch. Once the child branches are merged back into the feature branch QA starts, and as soon as the feature is approved it can be merged into main and released 🎉

Conclusion

Feature-based branching strategy provides a simple way of working your team and can scale to handle complex inter-dependant feature sets. If you’ve suffered the pain of git hell in the past: consider switching to a feature-based branching strategy.

Popular related posts for DevOps, Automation and CI/CD:

• Azure DevOps Pipelines: Frontend Code Quality Checks
• GitHub Actions: Frontend Code Quality Checks
• GitLab CI/CD: Frontend Code Quality Checks
• 5 steps to reduce your React app CI/CD build minutes
• What Are Diagram Scripting Languages?