Skip to content

Instantly share code, notes, and snippets.

@revett
Last active December 22, 2023 17:12
Show Gist options
  • Star 85 You must be signed in to star a gist
  • Fork 27 You must be signed in to fork a gist
  • Save revett/88ee5abf5a9a097b4c88 to your computer and use it in GitHub Desktop.
Save revett/88ee5abf5a9a097b4c88 to your computer and use it in GitHub Desktop.
Git Branch Naming Conventions

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
@revett
Copy link
Author

revett commented Oct 9, 2014

@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

@Crystalh
Copy link

Crystalh commented Oct 9, 2014

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 ?

@wildlyinaccurate
Copy link

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.

@wildlyinaccurate
Copy link

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.

@BlakeGardner
Copy link

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

@nowox
Copy link

nowox commented Jun 21, 2016

@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.

@Yousha
Copy link

Yousha commented Mar 7, 2017

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.

@zooxmusic
Copy link

zooxmusic commented Mar 29, 2018

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.

@Jake-Convictional
Copy link

Jake-Convictional commented Apr 24, 2019

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.

@alisonjs
Copy link

Is refactor a hotfix or feat branch?

@rw4lll
Copy link

rw4lll commented May 4, 2020

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).

@Fresh-Dev-zunairzakir
Copy link

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 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment