tldr; {type}/{group[optional]}/short-form-of-what-it-does
HCM developers consistently use dash-delimited branch names. About half also use f/
and b/
prefixes ('feature' and 'bug', respectively).
I suggest we continue our current practices, specifically:
-
a branch should start with a prefix indicating its type:
feature/
,bug/
,chore/
, orhotfix/
- prefer the whole word to the one letter abbreviation, the clarity outweighs the cost of the extra characters
feature
,bug
andchore
cover most of what we'd need; feel free to usehotfix/
for branches consisting of multiple urgent bug fixes
-
a branch should contain an optional group/team if it makes sense, e.g.,
onboarding
,pto
,esig
- the group should be something meaningful on its face, e.g., not
gobstopper
- the group should be something meaningful on its face, e.g., not
Slash delimiters in branch names can be a divisive topic, but I believe the pros outweigh the cons.
Pros:
- can use git pattern matching, e.g.,
git branch --list "feature/*"
- has the benefit of prompting some git GUI-based tools to allow collapsing token divisions like a directory list view
Cons:
- cannot have a branch name consisting entirely of one of our prefixes, i.e., "feature", "bug", "chore" or "hotfix"
- some people find the similarity to path names confusing
Some other branch naming tips:
Do not use use bare numbers (or hex numbers) as part of your branch naming scheme. Inside tab-expansion of a reference name, git may decide that a number is part of a sha-1 instead of a branch name.
E.g., If you tried to expand just 15032, git would be unsure whether you wanted to search SHA-1's or branch names, and your choices would be somewhat limited.
See:
http://mirocommunity.readthedocs.org/en/latest/internals/branching-model.html http://stackoverflow.com/questions/273695/git-branch-naming-best-practices
This looks great.