How do you name your git branches?

If I were less lazy, I'd probably reference an issue number, but I usually give my name and a description of the general task. In looking at current branches:

  ben/add-haptic-feedback
  ben/small-meta-fix
  ben/some-gardening

Git Flow is a well known and established way of handling branches that works really well on pretty much any sized project in my experience.

atlassian.com/git/tutorials/compar...

master = current state of the live site.

develop = stable development environment that keeps all developers in sync.

feature/feature-name = unstable new features under development or refactoring that might break the site.

hotfix = fixing a critical bug on the live site.

I see feature branches as being temporary (the branch is usually deleted after merge). What I find to matter the most are the commits.

The solution for references in the VCS will probably depend on the new issue tracker. If you're using Github to track issues, the org/repo#issue format works pretty well for issues that are across repositories. If the issue is in the same repository, it can be referenced simply by the issue number (#issue format).

At my company we use an alternative app (that looks like Trello), and we name our branches according to the task number in the URL (so if this is mycompany.com/task/38, we will git checkout -b t38, the "t" standing for task. We tried to name our branches by the goal of the fix/feature, but it quickly become unefficient because you need to think of a good name to illustrate your branches, and chances are that your branches will evolve and not only do what you intended in the begining...

So instead we put a link in the PR description in order to view the full spec of the issue or the feature. Maybe the best would have been to create git issues instead of Trello-like task, but this is already better and scalable for us right now.

I have a little script that takes the title of a Github Issue and kebab_cases it. I also prefix the Issue number, so all our branches are like:

5634-add-watever-to-watever
5670-fix-watever
5793-add-things

We use issue numbers a lot when we talk in the team, so when I want to checkout a branch, I just do git checkout the issue number and tab tab.

We do not prefix with the name of the developer because we have cases where one developer can take over the job of another developer.

If there is no ID possible, I usually try to come up with a description of the feature that is as short as possible.

This is what i do as well, if there is an ID available.

Depending on the projects structure, i define where the change occurs/what is affected.

An example: Adding a new Rest Endpoint to the backend for querying invoices:

backend/query-invoices

pre - for the pre-production environment
testing - for the integration environment
hotfix/DEV-1234 - for the hotfix branches, with DEV-1234 being the JIRA issue for the project
feature/DEV-1234 - for the feature branches, with DEV-1234 being the JIRA issue for the project

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.

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.

Branches in personal projects are just <bug/fix/feature?>_short-desc.

At work, my personal branches are named as abhnv/<sprint#/bug/feature>_small-description. We don't use issue numbers because Asana task ids are very long. We tend to put them in PR merges' commit message.