4 ms·

I disagree with naming conventions for branches. Just give it a name, I like to have have a bit of fun sometimes. For example: 'org-mode', 'more-org-mode' and '

I disagree with naming conventions for branches. Just give it a name, I like to have have a bit of fun sometimes. For example: 'org-mode', 'more-org-mode' and 'org-mode-3-still-org-moding' 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 'my-branch' I'm fine with it. Argue over something less pointless.

abhorrence 6y ago
I fall somewhere in between. I don't mind if the names are random and fun. But I do like: - avoiding the use of slashes (because with enough folks working on the same repo, you can get some crazy conflicts) - prefixing with some sort of "handle" (e.g. your initials) to help avoid branch name conflicts
- craigmcnamara 6y ago
  Yea, the slashes in branch names grates on me because '/' is a character that means too many things and the name winds up in URLs on Github.
- battery_cowboy 6y ago
  I made it a policy to only use a-z, 0-9, and _ in any branch, file, folder, or any other 'names' in the cli. Basically anything I'd type in the cli as an identifier/name. I find it prevents weird issues with characters when scripting and such, since the rest of the shiftable symbols on the 1-0 row (*, &, etc.) tend to cause issues when used too much in names because they're also used as operators and stuff. I think I started doing that with Windows filenames, since it has so many limits, and it crossed over into my Linux cli workflow.
bJGVygG7MQVF8c 6y ago
Agreed. Branches should be short-lived, anyway. If you need a long-lived pointer to a commit, use a tag. 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.
- hinkley 6y ago
  Can I see a live stream before I buy your e-book?
Arelius 6y ago
Yeah, I don't think you need to be over perspective over branch names. With the caveat that I like two guidelines: beginning branch names with the users name for a short user-specific feature. And something reasonably descriptive of what the branch is especially for non user specific ones.
mikewhy 6y ago
Agreed. Branch names are temporary and ideally not persisted. Same with commit messages in many workflows. If your branch names are ever exposed outside your team (like environment per branch or something) then yes, maybe you should be mindful of that.
kowsheek 6y ago
I had similar thoughts: https://blog.kowsheek.com/git-branch-naming-conventions-for-the-real-world/ https://blog.kowsheek.com/git-branch-naming-conventions-for-... The purpose of feature branches is agility and shouldnt be used to create more process.

abhorrence 6y ago

I fall somewhere in between. I don't mind if the names are random and fun. But I do like: - avoiding the use of slashes (because with enough folks working on the same repo, you can get some crazy conflicts) - prefixing with some sort of "handle" (e.g. your initials) to help avoid branch name conflicts

craigmcnamara 6y ago
Yea, the slashes in branch names grates on me because '/' is a character that means too many things and the name winds up in URLs on Github.
battery_cowboy 6y ago
I made it a policy to only use a-z, 0-9, and _ in any branch, file, folder, or any other 'names' in the cli. Basically anything I'd type in the cli as an identifier/name. I find it prevents weird issues with characters when scripting and such, since the rest of the shiftable symbols on the 1-0 row (*, &, etc.) tend to cause issues when used too much in names because they're also used as operators and stuff. I think I started doing that with Windows filenames, since it has so many limits, and it crossed over into my Linux cli workflow.

bJGVygG7MQVF8c 6y ago

Agreed. Branches should be short-lived, anyway. If you need a long-lived pointer to a commit, use a tag. 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.

hinkley 6y ago
Can I see a live stream before I buy your e-book?

Arelius 6y ago

Yeah, I don't think you need to be over perspective over branch names. With the caveat that I like two guidelines: beginning branch names with the users name for a short user-specific feature. And something reasonably descriptive of what the branch is especially for non user specific ones.

mikewhy 6y ago

Agreed. Branch names are temporary and ideally not persisted. Same with commit messages in many workflows. If your branch names are ever exposed outside your team (like environment per branch or something) then yes, maybe you should be mindful of that.

kowsheek 6y ago

I had similar thoughts: https://blog.kowsheek.com/git-branch-naming-conventions-for-the-real-world/ https://blog.kowsheek.com/git-branch-naming-conventions-for-... The purpose of feature branches is agility and shouldnt be used to create more process.