Git Branch Naming Conventions

git_branch_naming.md

Syntax

<author>/<type>/<ticket>/<title>

Example

revett/feature/24101/skeleton-service-for-email-sender

Explanation

<author>

GitHub username.

<type>

bug      - Code changes linked to a known issue
feature  - New feature
refactor - Code refactoring
spike    - Experiments 

<ticket>

Ticket/story ID.

<name>

• Use kebab-case
• Keep it concise

@darnould made a good point that using / messes up the Github URL structure, personally I never navigate around Github by changing that part of the URL, but it's something to think about. For example:

https://github.com/BBC-News/alephant-renderer/tree/feat/publisher-migration

I'd probably prefer a hyphen to a forward slash, unless Github is clever enough to visit a URL like:
https://github.com/BBC-News/alephant-renderer/tree/feat/
to see all the feat branches.
A hyphen might provide more flexibility on where the type is indicated: prepended vs appended.

What about considerations for components, e.g.:
stream-missing-images-bug or comp-stream-missing-images-bug
That way the branch's context is easily identifiable.

Maybe instead of junk we use spike ?

I don't think it's constructive to have branch name guidelines. Branches are supposed to be transient -- as long as the branch names are unique enough that people aren't conflicting, I don't see the problem in calling your branches whatever you feel like.

That's not to say that I disagree with having meaningful branch names as a courtesy to yourself and others. The style I use is #{JIRA-ref}-#{meaningful-description} e.g. NEWS-1234-fix-the-thing. Although lately I've been dropping the JIRA project ID, e.g. 1234-fix-the-thing which makes it easier to autocomplete branch names on the command line.

On a related note, it can be really useful to apply this sort of guideline to PR names and/or commit messages. @revett's suggestion is similar to how the Angular.js team do it (they do <type>(<component>) <description>, and I think it works really nicely.

Think i am going to adopt this for use within my organization. Thanks for the write up.

@Crystalh, why do you prefer junk over spike?

That said, I agree with the choice of slash over hyphen as separator between the <type> and the <name>. By design Git refuses to have a standalone branch with the same name of an existing <type>. This reinforce the image (and the fact) that types are like directories with branches in it.

Its almost opinion based...

And you forgot "release" and "integration" type(group)
Also "feat" is NOT a common term and confusing readers... use "feature" instead.

wildlyinaccurate just my opinion of course I'll try to back it up with usefulness. I think it is actually very constructive to standardize as much as you can. The first benefit would be that if you do not really KNOW the name of something, if you are intelligent and observant you should be able to guess at a name hence saving you time. Another real benefit is that if people actually name it to what it actually is or does, you don't need to read the entire code base to figure this out, hence saving even more time. (Of course a ton of people are not skilled in reducing the main concept or keywords of an item but this should be improved) Other benefits are more stylistic but have a basis in human nature I believe. If you look at all the names they would be much more uniform and pleasant to look at. The example I will pose is walk into a very organized grocery store in which all the products are lined up and moved to the front of any and all shelves now contrast this against a grocery store that just doesn't give a shit and all the shelves are just in disarray such as your local KMart. I would be curious if I am the only one that would, without a doubt and without any hesitation go ONLY to the organized grocery store instead of the "shit" one. This is one of the perspectives that makes me want to quit computers. There are way too many ways to skin a cat and so many people just ignore standards or don't want to spend the time to figure out the "better" way to accomplish something.

An advantage to the ###-name format is that if you use tab to autofill branch names (ie. when checking out) you always get a unique identifier at the beginning. I'm not sure I see the usefulness in labelling the branch with feature, bug, hotifx, etc, when I can just go to the issue and see that information in the label.

Is refactor a hotfix or feat branch?

Is refactor a hotfix or feat branch?

If this code should be deployed right after it was completed, it goes to hotfix. I think it doesn't matter what inside, bug or feature.
If this code is in plan, it should be named depending on it's purpose (bug/feature/etc).

For the title/description dev can mention it on the pull request or the scrum master can check the details from UserStoryPBI/Bug number on DevOps.

For Example:

for PBI: PBI--DDMMYYYY(startdate)
for User Story: US--DDMMYYYY(startdate)
for Feature: Feature--DDMMYYYY(startdate)
for Bug: Bug--DDMMYYYY(startdate)
for Task: Task--DDMMYYYY(startdate)

The title is not necessary to mention in the branch name because sometimes a branch can contain multiple fixes, It's better to mention the related work on OR OR .