How do you name your git branches?

I'm currently evaluating an alternative to Jira for managing our software development projects at work. One of the things that I'm having a hard time moving away from is Jira's ability to have keys and auto incrementing ID for each task/issue.

So let's say I've got a DEV.to project setup, I could set a key as DEV and each issue I create will have a prefix of DEV-. Currently we will use this key and ID combination to also name our git branches in source. So if the issue is 23, then our branch would be cut as DEV-23 and then it's easy for us to track from VCS to Jira to PRs on BitBucket.

But as I'm evaluating alternatives, I'm realizing this key/id might be unique to Jira or software development management tools.

So my question is, if there is no key or ID and you're working across multiple projects, what sort of naming scheme do you use for your git branches?

Comments

[kgrosvenor]

imo branches should contain the ticket number and a short description like this is to retain semtantics of a Git repository.

feature/JIRA-112-my-awesome-feature

[Michael Lee 🍕]

Thanks for sharing. But...but emojis is life.

[fluffy]

Generally I do contributor/issuenumber-briefname, e.g. fluffy/294-fix-broken-frobnicator. If it's an ad-hoc topic branch I'll leave out the issue number if I don't feel like going through the rigamarole of opening an issue first.

For release staging I do e.g. release/v0.1.9 or maybe release/v0.1.9-new-haptics if there's a specific impetus or major feature to the release. (And of course when I cut a release I tag the commit that was used to build it.)

On projects where either I'm the sole contributor or I expect other people to work in their own forks, I generally use feature instead of contributor name (e.g. feature/123-object-hierarchy or whatever) although that's more a force of habit at that point since it's not like there's any point to namespacing my branches.

[Ozkar L. Garcell]

In my team we use to name the git branches following this pattern:
username_#issue_short_desc. Is really hepfull in medium teams with a lot of issues.

[Gift Egwuenu]

Where I work and generally I do mine this way:

ft-name-of-the-task-#story-id
It can either be a feature, bug or chore with that I just prefix with the type of task I'm working on.

[K]

master

[Electrode Cathode]

Where I work we name our branches like so.
For any new feature you want to add :
feat/user-email-notifications
For any bug fix
fix/user-signup-buttons

[Truong Hoang Dung]

Naming is hard, it's unsolved problem actually.
But we should follow a consistent principle, in my case, it's about do-something.

[Akash Kava]

+ master
+ dev
+ v2018
  + feature1
    + root
    + user1
    + user2
  + feature2/sub-feature
    + root
    + user1
    + user2

Turns out that some features are re engineered over years so root year folder helps in isolating feature names. Also root branch is created to differentiate sub feature folder as you can have sub folders inside features.

Ideally it is bad practice to have too many feature branches, and too many branches as well.

Best way is to distribute code across multiple repositories and either create packages with good package manager or use links with sub repositories.

[Thomas H Jones II]

Overall, we use a fork-and-branch model. The rest depends on where in the project lifecycle things are and what our customer-dictates are.

Early in a project-lifecycle, there often aren't "issues", per se. It's usually "we need IOC by <insert date that's some fraction of the length of time that it likely ought to be>". It usually works out to a flow like:

• initialize project in relevant git-service: do the initial commit so you can begin to branch; set up branch-protection on the base-branch(es)
• Gen-off a "project-scaffolding" branch: add issue templates, MR/PR templates, contribution guides, CoCs, baseline test-configs (syntax linters for the languages/frameworks to be used), etc. Then merge that in
• Start forking off IOC-supporting branches (naming is ad hoc)

Because we do work for multiple customers, things begin to deviate once the above is done. Some customers want issues managed in Jira. Some want issues managed elsewhere. Some are fine leaving them wholly contained within a given git service. Once we're to the point that there's discreet defined tasks that need to be individually coordinated and tracked, then we start using the customer-preferred tracking system. For tasks tracked wholly within the git service, we usually just do "Issue_<NUMBER>" to reflect the git issue-ID. If customer is mandating Jira, then we usually do "<PROJECT_ABBREVIATION>-<NUMBER>". For other issue tracking systems, we do either whatever's native to that system or whatever the customer asks.

...And if we're doing stuff on spec (anticipating a need for a customer or our own organization), then it's pretty much dealer'sdeveloper's-choice.