Git gud with branch naming

With this post I want to share my approach to Git branch naming. This is the 4th and final post in the naming convention series .

When working in large teams, managing branches can quickly become a hassle. Comparing branches to figure out their feature set, is a time consuming and error prone activity. This should be avoided as it significantly increases the chance of releasing wrong or even broken functionality.
The most ideal solution here would be to use a backlog tool (for example Azure Boards with Azure Repos or with Github) where the branches can be directly linked to backlog items and visa versa. And dotting it i’s by implementing a proper branch naming convention.
However teams that do not have these tools available to them would need to rely on just the naming convention to help organizing and ordering branches.

A friend of mine recently looked into an Azure DevOps project and just a single repo had over 600 active branches (this sounds like a separate problem, I know). What really made it difficult is that also the branch naming was all over the place. Here is a small example of just the feature branch variations:

In the following chapters lets have a look at the steps needed for the owners of this project to improve their situation with a naming convention.

Establish branch types

Always start by identifying and agreeing on the type of branches your team will use as this can vary based on the preferred branching strategy. If unsure, generally speaking the following branches should cover most commonly used strategies.

• develop
• main
• hotfix
• feature
• release

The branches with an infinite longevity like main, master, and development can be excluded from any naming convention as their names are set only once during their lifetime. However the branches of a short longevity and which exists in multitude (as mentioned in the earlier example) should be subjected to a naming convention. For these type of branches follow up by detailing out the approach to their naming. Let’s apply this on the above mentioned branches.

Hotfix branch

Hotfix branches are always prefixed by ‘hotfix’ followed by a forward slash ‘/’ and finally the hotfix identifier. The hotfix identifier should always correspond to a backlog item number of the bug or hotfix in question. If the team prefers a more descriptive approach the name of the hotfix can be used as a suffix. However I am against just using the name without any identifier as teh name of a backlog item can be subjected to change

An example:

Feature branch

Feature branches are always prefixed by ‘feature’ followed by a forward slash ‘/’ and finally the feature identifier. Similar to the hotfix branch the feature identifier should always correspond to a backlog item number. And based on the teams preference a descriptive suffix can be added.

An example:

Note: The backlog item does not have to be of type feature as it is not a direct correlation to a backlog item of the type feature but a reference to a functionality feature. So it can be of any type e.g. task, user story or even a subtask.

Release branch

Release branches are always prefixed by ‘release’ followed by a forward slash ‘/’ and finally the release version number. As a fan of the semantic versioning approach I like to use it when requirements and constraints allow for it.

An example:

Wrapping up

And that is all I have to share on this topic. Thanks for reading this post and if you haven’t please check out my previous post on this subject.