Git Branching Naming Convention: Best Practices.

Git offers flexible branching strategies, but what does it mean? In simple words, a branching strategy is a set of rules, a convention that helps our team.

Git branching strategies allow the separation of work. Broadly, we can divide Git branches into two categories: Regular & Temporary Branches.

Regular Git Branches

These branches will be available in your repository on permanent bases. Their naming convention is simple and straightforward.

Git Branch

• Development (dev) is the main development branch. The dev branch’s idea is to make changes in it and restrict the developers from making any changes in the master branch directly. Changes in the dev branch undergo reviews and, after testing, get merged with the master branch.
• Master (master — main) is the default branch available in the Git repository. It should be stable all the time and won’t allow any direct check-in. You can only merge it after code review. All team members are responsible for keeping the master stable and up-to-date.

Temporary Git Branches

As the name indicates, these are the branches that can be created and deleted when needed. They can be as follows:

• Bug Fix
• Hot Fix
• Feature Branches

Git Branching Naming Convention

1. Start branch name with a Group word

It is one of the best practices. The group word can be anything to match your workflow.

Feature/…
BugFix/…
HotFix/…

2. Use Unique ID in branch names

The name shows that the branch applies to the task of adding a testing module, in our case could be the Jira ticket.

TEAM-XYZ

So we have something like this:

Feature/TEAM-123…

The name shows that the branch applies to the task of adding a testing module, the tracking Id of the issue is TEAM-123, and the work is in progress.

One more advantage of using an external tracking ID in the branch name is the possibility to track the progress from an external system (Like our Atlassian Environment)

3. Use Hyphen, Underscore or Slash as Separators

There are two main advantages of using a separator in the branch name:

1. It increases readability and helps to avoid confusion.
2. It makes it easier to manage, especially if you are dealing with many branches.

we want to avoid this:

featureupgradejqueryversionloginmodule

by the use of this:

feature/TEAM-123_upgrade_jquery

What we don’t want?

Avoid using numbers only: if there is a branch name 9912 — what should this magic number tell us? It only means more confusion and risk of mistakes, especially during merging with other git branches.

• Avoid using all naming conventions simultaneously: Mixing and matching all Git branch naming conventions are not the best practice. It only adds confusion and complicates the overall processes.
• Avoid long descriptive names for long-lived branches: The essential quality of a branch name is that it should be precise and informative. Let’s have a look at some examples again:

feature/PROV-123_login_module_which_will_used_in_the_public_website
feature/PROV-123_login_module_which_will_used_in_the_internal_website

What is going to be our convention then?

Given this our naming convention is going to look like this:

group/ID-Name

an example of this can be:

feature/TEAM-123-fast_api_call