Branching Strategies
Last modified on Fri 01 Dec 2023

Branching strategies

Branching strategy is a set of rules created by developers used to achieve a consistent team-level approach to the management of git branches within a project.

There are many possible branching strategies. Good branching strategies follow two basic rules:

  1. Reduce the number of merge conflicts (main cause: changes of the same resources by multiple authors and long-living branches)
  2. Allow deployments based on the client and project needs (main goal)

Good branch naming

When creating a new branch, name it consistently to the team's branching strategy. First, determine the type of the branch (release, feature, hotfix). Second, describe the purpose of creating a branch using not more than a couple of words. Following are some examples of branch names according to these rules:

Examples of branching strategies


GitFlow is one of the most popular branching models used commonly within the .NET team. Its main advantage is that it supports projects where deployments are often. Since we use agile workflow, this goes hand in hand with it. We will cover some of the things about GitFlow in this handbook, but you can find a broader explanation here.

This image shows the diagram of GitFlow branches:



The master branch (sometimes called main) should only contain a release-ready code and is one of the two branches from which code is released.


The develop branch is the second branch from which the code is released (for the development environment). It should only contain the code which is ready to be part of the next release. When it is decided that a new release build should be done, a release branch is created from the develop branch. After a successful deployment, we merge the release branch into the master and back to the develop branch.


Each new feature needs to be implemented in a separate branch. It is always branched off from the develop branch and merged back into it. Feature branches also have a naming convention we should follow:


If the project uses a feature tracking system, it is necessary to put the ticket identifier into the name as well:


If there is a bug or a priority request for a change that needs resolution in production as soon as possible, we can create a hotfix branch. A hotfix is branched off the master branch and merged back into it and develop. We use a standard hotfix naming convention similar to the feature one:

Pros and cons

GitHub flow

GitHub flow is a simple flow having only one long-living branch (master/main) from which feature branches originate. After work on a feature branch completes, changes are merged to the master branch using a pull request.


(image source)


GitLab flow

GitLab flow introduces environment branches to GitHub flow (e.g., staging and production).


The GitLab flow is based on 11 rules:

  1. Use feature branches, not direct commits on master.
  2. Test all commits, not only ones on master.
  3. Run all the tests on all commits (if your tests run longer than 5 minutes, have them run in parallel).
  4. Perform code reviews before merging into master, not afterward.
  5. Deployments are automatic, based on branches or tags.
  6. Tags are set by the user, not by CI.
  7. Releases are based on tags.
  8. Pushed commits are never rebased.
  9. Everyone starts with master and targets master.
  10. Fix bugs in master first and release branches second.
  11. Commit messages reflect intent.

Trunk based development

This branching strategy is explained in detail here.

Basic rules


Previously shown branching strategies are just examples of best practices that may or may not fit the needs of a specific project. Therefore, choosing the one that works the best should be done by following the already mentioned good branching strategy rules and taking into account the professional experience of team members and team processes.

You can learn more about git branching by using interactive web tools like this one or by reading this Medium article by Patrick Porto (used as a source for this article).