Question: why release-1.0.0 vs. release/1.0.0

[Jaykul]

For short-term branches I don't care much -- seeing them helps you remember to make sure they're closed, but for long-term release branches....

Many GUI tools (specifically including azure git which my employer uses, but also tools like gitkraken, source tree, etc.) show path-like branch names as folders, so if a team uses / instead of - as the separator, then releases are rendered neatly as if in a folder (and are hideable when you're doing normal work and don't care about them).

I noticed you don't favor the feature/ type prefixes for branch names either and I wondered if you're against path-like branch names in general (and if you have a reason), or if you have a reason for avoiding them here (since you specifically left the option open on change branches)...

As an aside: I'm actually updating git workflow policy for an org with more repositories than feature teams. Our teams work across all repositories (in theory), so we're considering recommending developers create branches like teamname/change-description or even teamname/storyid/change-description (where the story id is in our issue tracker) so that other developers can easily tell which teams are currently working on any project, and even look up the big-picture information about it ...