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

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