You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ...
The text was updated successfully, but these errors were encountered:
Jaykul
changed the title
Question: why release-1.0.0 vs. release\1.0.0
Question: why release-1.0.0 vs. release/1.0.0
Nov 28, 2018
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 eventeamname/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 ...The text was updated successfully, but these errors were encountered: