Git Branch Naming Conventions
deepsource.io
deepsource.io
Nothing inherently wrong with having the number in the branch or commit-message, but please make sure the rest of the name/message stands on its own.
This is why I generally prefer using the full issue URL in comments, but that is unwieldy for branch names.
"Fix for PJ-1029: Screen flicker on GTX1070 while jumping off cliff"
I love the "naming branches for modern git workflows" in the subtitle...
You wouldn't want to be the odd developer out naming their branches like in those un-modern git workflows, would you? Well then, you should buy my e-book and Egghead course, subscribe to my tinypost, and follow me on Twitter.
The principles of marketing don't change, folks.
The purpose of feature branches is agility and shouldnt be used to create more process.
Prevents strange issues when you use a case insensitive file system like on OSX or Windows
fsutil.exe file setCaseSensitiveInfo "C:\path\to\dir" enable
(Each volume can also use an extra encryption layer if you want, which can be super useful.)
Also just finished migrating something that ran on IIS to linux, and got the casing pains once again.
If the universe were to be reinvented, I ask please make everything case sensitive by default
There’s an analogous tree for remote branches!
I don't what the definition of a 'feature' is. Is it a task or something bigger than a task?
I'm not a huge fan of overly verbose commit messages. They can make the job of compiling release notes annoying.
It's certainly possible to configure that sort of integration. But it won't just happen out of the box.
Commit messages have little to do with releases or release notes. I'd argue either your commits or your release notes are most likely wrong in some way if you are doing that.
https://manpages.debian.org/testing/git-buildpackage/gbp-dch...
1. Use All lower case. It's impossible to be consistent with any other case (except all upper case). This is important. Git does NOT like case insensitive file systems, and people having two branches with a segment with different case causes problems.
2. Use path segments to group branches. Categories can be versions or a specific team or user e.g. version/v1.0 or topic/desktop/123-add-printing-support or /topic/jimbob/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.
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/123-fix-blank-password-always-accepted and topic/blank-passsword-always-accepted-on-version-v1.0
Totally agree on all lower case.
If there's no good reason to do that, just don't.
Do you recall any of the problems you had? I'm frequently using checkout/rebase/merge workflow and never had any problems. But I always felt I am not using all features got had to offer.
Slashes in branch names are BAD ideas and should be avoided.
My thoughts are: They don't really add any value to the branch nor do they inform the developer. Identifying a bug fix, a new feature, or a document branch doesn't change the way you treat the branch in any way, nor would it necessarily prioritize the branch.
If you are drowning branches (like dozens or hundreds) and need to categorize them like this, it's somewhat a "code smell" reflecting the development process. Having too many things open and not closing them is not the greatest strategy.
Anyway, honestly interested in your opinion and why you find those prefixes useful. They seem to me to be some holdout from early blog postings recommending this approach, but turn out to not really add any value.
We review tickets / pull requests. Tickets should already be prioritized, be tagged as task/improvement/fix, and pull requests are displayed in order of creation. No need to worry about branch names. Just use either the ticket code, or the title (or code-title)
<alias>/<yyyyMMdd>_some_short_description
<alias>/<yyyyMMdd>_<task-id>_some_short_description
I'm not a huge fan of the timestamp as it makes viewing a list of branches a little noisy. I think instead you can use this[0] solution to delete branches older than X days.
Slightly different from what you are referring to, but I have the following aliases that are super useful for cleaning up dead branches locally. They make running `git branch` actually return a reasonable list of branches rather than every branch I ever checked out in the past eight years.
listdead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}'\""
prunedead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}' | xargs git branch -D\""
Then I run `git prunedead` and it goes through and actually deletes them.
I've never run into a case where branches I didn't want removed were in the dead list, but I usually run `listdead` first just in case.
I think I swiped these from a StackOverflow answer at some point. Don't remember.
refage = ! git for-each-ref --format='%(committerdate:relative),%(authorname),%(refname)' --sort -committerdate | column -t -s ','
For remote, you should just delete when you merge OR, when doing the cleanup, delete the old and merged branches.
For local, just remove branches that are not on remote anymore
This raises the question of using "-" or "_" for divider. Keep in mind there are words that may have "-" (e.g "self-expression"). And as far as I know there are no words that have "_".
In summary: And so I have decided on using "_" as my divider and plays well with other integrated tooling for future robustness.
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.
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.
Indeed, we're a small shop, but I can'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.
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 usually use "feat/my-branch" or "fix/my-branch" depending on the purpose of the branch.
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
That allows easy ticket number extract using grep.
git branch -b ohnowhathaveidone
git checkout -b ohnowhathaveidoneI usually just do names like `dev/short_description`, but that is still a naming convention.
Unless there are many long-lived, public, collaborative branches there's little need for careful and deliberate naming convention across a team. And if you have enough of those kind of branches, I contend that you're not merging enough.
Unless your machine is automatically backed up every hour, in which case ignore me.
That has not been the case in most of my jobs, but pushing my WIP branch to a remote every hour or two achieves that goal in practice (as long as I don't have anything important that's not in a repo).
"Walking conventions:
1. Stand.
2. Move right foot ahead.
3. Move left foot to match.
That's it. You can also do it the other way around, but be consistent."