Git Branch Naming Conventions

I&#x27;ve seen projects outlive multiple issue-tracking systems.<p>Nothing inherently wrong with having the number in the branch or commit-message, but please make sure the rest of the name&#x2F;message stands on its own.

I disagree with naming conventions for branches. Just give it a name, I like to have have a bit of fun sometimes. For example: &#x27;org-mode&#x27;, &#x27;more-org-mode&#x27; and &#x27;org-mode-3-still-org-moding&#x27; are 3 real branches I recently shipped. All the naming convention does is make another pointless argument. As long as the name is more descriptive than &#x27;my-branch&#x27; I&#x27;m fine with it. Argue over something less pointless.

Just want to throw a small one in there: branch names are all lower case.<p>Prevents strange issues when you use a case insensitive file system like on OSX or Windows

A handy thing about jira is that the ticket picks up the commit automatically, so anyone viewing that ticket can go straight to the changes if the branch begins with the ticket id.<p>I don&#x27;t what the definition of a &#x27;feature&#x27; is. Is it a task or something bigger than a task?<p>I&#x27;m not a huge fan of overly verbose commit messages. They can make the job of compiling release notes annoying.

I&#x27;ll add some more I find useful:<p>1. Use All lower case. It&#x27;s impossible to be consistent with any other case (except all upper case). This is <i>important</i>. Git does NOT like case insensitive file systems, and people having two branches with a segment with different case causes problems.<p>2. Use path segments to group branches. Categories can be versions or a specific team or user e.g. version&#x2F;v1.0 or topic&#x2F;desktop&#x2F;123-add-printing-support or &#x2F;topic&#x2F;jimbob&#x2F;123-add-printing-support Many systems will display these segments in a tree structure so you can quickly navigate all branches of a specific kind e.g. all your ongoing work separate from 20 version maintenance branches.<p>3. When making branches to cherry pick hotfixes to a different branch, include the new target branch in the branch name to avoid confusion. E.g. topic&#x2F;123-fix-blank-password-always-accepted and topic&#x2F;blank-passsword-always-accepted-on-version-v1.0

As a side note, I always found it annoying to use “feature&#x2F;123” instead of “features&#x2F;123“. Just like in REST APIs, the slash brings to mind a collection or a file system directory, both of which should be pluralized.

gitlab is already doing this. The default branch name when you click `Create Merge Request` is issue_id-issue_title, like &quot;477-update-readme-md&quot;

I like throw an alias and date stamp in their too:<p><pre><code> &lt;alias&gt;&#x2F;&lt;yyyyMMdd&gt;_some_short_description &lt;alias&gt;&#x2F;&lt;yyyyMMdd&gt;_&lt;task-id&gt;_some_short_description </code></pre> as it makes cleaning up old branches (both local and remote) just a little bit easier. Author left the team? Delete. Untouched from 6 months back? Delete.

<a href="https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;</a>

Personally I like the `ft&#x2F;...` format using &quot;&#x2F;&quot; for divider. However, it does not play with other software especially when the url is involved (e.g. the branch name collides with url path). This issue fits loosely similar problem to file naming to avoid problems (e.g. avoid &quot; &quot; (space), &quot;-&quot; (dash), or use of any weird characters as part of filename. This is the reason why you may find a lot of files named with &quot;_&quot; (underscore), especially in place of a space.<p>This raises the question of using &quot;-&quot; or &quot;_&quot; for divider. Keep in mind there are words that may have &quot;-&quot; (e.g &quot;self-expression&quot;). And as far as I know there are no words that have &quot;_&quot;.<p>In summary: And so I have decided on using &quot;_&quot; as my divider and plays well with other integrated tooling for future robustness.

A bit late to the party but I&#x27;m going to suggest something entirely different.<p>At my shop we often use a setup comprising simply of a develop branch, a staging (test) branch, and of course master (as the live productive branch), and we have build processes for both staging and master, which may differ slightly based on the test vs. live environment.<p>We only use separate branches for possible new breaking features that could cause hold ups in this chain. Otherwise, the work flow is develop on develop (obviously :) ), test on staging, and merge to master once all tests pass.<p>Indeed, we&#x27;re a small shop, but I can&#x27;t help but recommend having these three key branches. Even at a larger organization I could see this working, only maybe having more separate feature branches as branched off from the develop branch.

&gt; For example, there could be multiple branches needed to work on one issue, possibly by different people.<p>I would say that in a case like this, probably you need to break that issue into smaller tasks? Otherwise, how you keep track if the ticket is ready for review, which parts are completed, etc?

I like the &lt;feature&#x2F;featurename&gt; naming scheme because in some Git software (at least in Visual Studio) all of the branches starting with &lt;feature&#x2F;&gt; will show up in a collapsable folder named <i>feature</i> in the interface.

underscores or GTFO, so you can double-click to select the full branch name!<p>we also tend to prepend with our initials just in case someone else also has a branch related to that issue and they give it a similar descriptive slug

I like to separate the issue tracker number from the rest of the branch name using a &#x2F; where the rest is separated by either a - or _<p>That allows easy ticket number extract using grep.

Another tip to add to point 2: keep the scope of each branch limited so that the resulting name can be short. E.g. a branch with feature1, feature2, and fix3 should be 3 separate branches. Combining too many things into one branch is a common mistake, and a side-effect is that it&#x27;s impossible to come up with a short name for the branch.

I use the same convention but whatever you do, be consistent even if you don&#x27;t intend to push a branch to a remote.

Good advice. I usually like to put the ticket number at the end just because it makes autocomplete a little easier.

Wait, are you telling me that<p><pre><code> git branch -b ohnowhathaveidone </code></pre> isn&#x27;t right??

if you need a branch naming scheme, then you probably have too many public branches.

If this can make HN, here&#x27;s my news item:<p>&quot;Walking conventions:<p>1. Stand.<p>2. Move right foot ahead.<p>3. Move left foot to match.<p>That&#x27;s it. You can also do it the other way around, but be consistent.&quot;