Git branch naming for Azure DevOps


Git branch can have quite a long name – even up to 250 characters! Today I show how to utilize this under certain circumstances, i.e. using Azure DevOps with a certain work items schema. 

Azure DevOps workflow

We use tickets as containers for the issue. An exemplary ticket named „Letter 5 XML file guarantor section issue” on the picture below holds three bugs for three different product versions. Usually, when developers start working with the ticket, they fix the issue on the one version branch and then port the fix to the other versions.

Ticket with bugs belonging to different product’s versions

At least that’s the idea. When the fixes are ready, code reviews are performed, all versions must be built using DevOps pipelines (separate for each product version) and passed to the testers.

If there is no flaw, then all feature branches must be merged to main version branches. It’s simple and works for us.

I like such a simple workflow, especially the connection between tickets and bugs. On the board I can easily see all the tickets I’m assigned to, in which stage each ticket is, and what to do next.

Board with tickets and subsequential stages – from the backlog to close state
Me, when testers finished their work and assigned me back to the ticket I’ve already forgotten.

How branch name can help here?

Git is very flexible if it comes to branch naming. One can easily check whether the desired name is valid using the command git check-ref-format –branch branchName. The name may be quite long – even up to 250 characters if you use only the ASCII table (as I usually do). So we may name the branch like Ticket1234_Pawel_Description or something similar. But maybe there is a better, more structured way?

I invented 🙂 my own which helps me a lot. Let’s assume that I work with the ticket described above. I have then to create three branches started from version branches 21.1, 21.2 and 22.0:




The pattern is clearly visible. Users followed by my name shortcut. Then the ticket number with a short, meaningful description (might be longer if needed). Then bug number and target version.

Why is it so good?

First of all, take a look at my git client:

The naming template I use allows to group all branches related to the same ticket in one place.

What do I need to do, besides the fix on the branch? Many administrative tasks.

  • Add the branch as related to the bug
  • Issue Pull Request (targeting appropriate release branch)
  • Build the branch to pass installer to the testers
  • Beware not to do any mistakes which may be hard with all those similar, six-digit numbers

On each of these steps, our naming template will protect me against making mistakes. I can always copy part of it and search for bug/ticket. I instantly know what this ticket is all about, as the name contains a short description. Many, many times it will be useful and frankly speaking, I haven’t found any other naming convention nearly as useful.

I encourage you to try it out. In case you will find a way to improve it, please let me know. I will always embrace good ideas 🙂

0 0 votes
Article Rating
Powiadom o
1 Komentarz
najnowszy oceniany
Inline Feedbacks
View all comments

[…] In the previous article, I mentioned that Git is very flexible in naming branches. And I usually use this flexibility. My standard branch name is: […]