[xyzzy_plugh]

> ticket: is a branch for each JIRA ticket not each feature.

This kind of thing really grosses me out. Why can't you just include the issue number in relevant commit messages? Why does it matter what your branches are named?

Naming branches relevant to what they actually represent is incredibly important to me, personally. I don't care what you do but I refuse to play by this rule in particular, when it's a hard rule.

[gregmac]

I've worked with lots of variants, and by far I find using both works best: feature/PROJ-124-user-edit or bug/PROJ-234-startup-crash

This unambiguously lets you trace back to the ticket (as either the author or owner), but keeps the branch readable (you don't have to go to the ticket to see what it is). It also makes the merge message (containing the branch name) much more useful when looking back months later.

It works with multiple branches per ticket (which I often do to make PRs easier): feature/PROJ-456-refactor-config, feature/PROJ-456-config-ui

It avoids having to worry about the text name. There's no worry about duplicates, either current or historically. It can also be short: just descriptive enough so someone looking at the branch list can see what's what, and you can find yours without memorizing ticket numbers.

The ticket is also very useful when you're cleaning up old branches: maybe there was a different fix and this was abandoned, or maybe it was blocked and then forgotten? The ticket can answer that.

It's very low effort: you naturally know the ticket when creating the branch. After that, you just work on the code, and when you're done the ticket number is right there for you - no searching, sticky notes or kanban board necessary.

Edit: the bug/ or feature/ prefix is optional, but keeps the display way nicer: most UIs will treat it like a folder and allow to collapse, keeping the top level organized and tiny. The classification is also easy and useful - at a glance you can see if it's mostly fixes or new features happening (without looking at your issue tracker). For products with released versions, release/1.0, release/1.1 etc works well for the same reason.

[PontiacParade]

Sorry, I didn't mean to imply that the branch is named for the JIRA ticket. I personally like to have the ticket number in the branch name along with a description though. It was more that each ticket branch is for a small chunk of work that can be merged and deployed when a single ticket is complete not when the whole feature is complete.

[jameshart]

Weird. In a GitHub-flow model I don’t care about branch names at all except inasmuch as that they need to be unique.

Branches pushed to origin are just a backup of the commit log that leads to a pull request - they’re ephemeral, belong to the pulled request author(s) and are nobody else’s business but theirs.

[enraged_camel]

I don't know about Jira, but Gitlab has a pretty cool thing whereby it can detect the relevant issue when you git-push a branch to the repo, by looking at the branch name (e.g. 123-some-issue is linked to issue #123).

[secondcoming]

This works with Jira too. It automatically links to the ticket commits

[patrickthebold]

Not gp, but I (almost) never read commit messages. And usually tickets are so amorphous that it's hard to come up with a good name for the branch,so I always use the ticket number.

Of course, I have no problem with well named branches, but when not doing it by ticket number, you tend to get nearly meaningless branch names: search, fix_color, tooltip, search2.

That said I'd never mandate it, it just seems easier.

[xyzzy_plugh]

I have the opposite experience across the board. The ticket number tells me nothing, I can't grep for context, git blame turns to utter noise.

I constantly read commit messages. Branch names are usually similar to commit messages: xyzzy/fix-menu-style or xyzzy/add-menu-tooltip.

If you just wrote a commit message that's just a ticket I'd block your review until you wrote a proper message and it's a hill I'm happy to die on.

[graton]

But now the development is pretty much tied forever to the issue tracker. As to read the code history need to have the access to the issue tracker to understand the reasoning. Which to me sounds like a bad idea for the future.