Not a huge fan of branching, for I fear the worst when you decide to merge.
That being said, at a company I used to work for we named our branches based on our internal beta releases, something like:
repo-name/IB-1 repo-name/IB-2
I've started to use my own model to make not long-living branches and is a sort of combination between the Successful Git branching model adn the BEM Methodology for CSS. So if i have to add an API feature that returns cute kitties picttures I'll do something like feature--api-kittens or sort of. I've only used on a few personal projects to feel "creative".
We use something like:
/feature/[trello-card-id]-short-description
/issue/[trello-card-id]-short-description
/hotfix/[trello-card-id]-short-description
Where [trello-card-id] is optional, if it's related to a card added to trello we use it, otherwise it's skipped.
And then we try to use the git-flow methodology.
We use prefixes, so hotfix/, feature/ etc. and we tend to use ticket numbers, so feature/EN-333 and we encourage short descriptive suffices, so in the end something like this -> feature/EN-333-fix-sorting-by-price
I use git-flow, so the almost all my branches (which not are neither develop or master) are feature branches, I use to name this branches a descriptive name with a hyphen separating words: ej. enable-eslint, better-logging.
This aproach is has been well received on my team since it's fairly semantic.
Our team use to name our git branches with combination of feature name, types of environment and date created. For example:
fetchprofileinfo-development-12152016
feature/feature-namebugfix/bugfix-namehotfix/hotfix-name
etc.hotfix/mobile700-_Simple_fix
type - project name (mobile, desktop, team) id - JIRA number descr - short description
New practice we are trying to follow is mark in the name the father branch, because many time you loose track from which branch was created... This is one of the git drawbacks
i tend to use the [type]/[owner]/[name-of-the-branch]
something like:
it's nothing special but I can see who is working on which branch / what it's general category / what is happening inside.
Prefixed with bugfix, enhancement or feature, followed by a short description like feature_post-on-hasnode. Description could be also a direct reference to an issue.
Agree with what's been said here already, although rather than issue i use a
defect-XXXX-short-description
And for features I'll do something like this:
feature-name, so something like feature-add-ability-to-download
I mostly use issue_<number>. Replace the number with the issue number. Like : issue_100.
Required is something like github, gitlab, redmine, ...
For issue branches: <issue-key>(optional-keyword), all lowercase, hyphen separated. eg...
abc-123abc-123-new-feature-nameThis matches the commit message convention of "<issue-key> plus short description".
Since we use Bitbucket and JIRA, pretty much wherever the JIRA key shows up it's a link back to the issue; and the issue links out to the pull request. Links things up nicely. Some teams actually create the branch from the JIRA page to ensure the key is correct.
Other than that we basically only have master and branches named according to the test server they deploy to.
Here are some branch name conversions that i use
Use hyphens to separate parts of your branch name
here-you-go
Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
To know more about feature branches, click here.
Maximilian Berkmann
Web and programming
As some people already said there's:
Of course, there's plenty other ways to name branches according to how your workflow is set up and what branch should contain what and how accessible each of those branches are.