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?
Oldest comments (39)
Key prefix is here typical for Atlassian Toolchain because it will connect / link different components of whole system together, for example: BitBucket/Git branch or Bamboo build to actual Jira issue ticket. In addition it is useful when branch briefly describe its purpose, i.e.:
feature/DEV-42-dark-theme or bugfix/DEV-666-fix-comments-box
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:
I got a little too generic at one point, reused a branch name and halted the server's code from updating (the person reporting the stall didn't know
git fetch --pruneā¦ my office is a relatively recent git convert. don't judgeā¦ ).I use a version of Ben's:
Useful side effect: keeps little reminders for myself come time for annual self evaluation.
This is pretty much what I do, our agile tracking software at work (Clubhouse) gives you tags based on the issue number, which automatically connects the ticket to the branch. You end up with branches that look like this:
They have a nice copy button, which makes it easy to check out new branches.
If I am working on a non-work project, I use:
start a new branch from there?
why your name is relevant to the feature? does someone who takes it over (in case you get sick or you take 1y off time) needs to rename it? Just my curiosity... Thanks
Why is your name important in naming a branch? To indicate the assignee? What happens if the issue gets re-assigned?
Good point Nada
Here's something I want to try in the near future, and it's entirely inspired by Phabricator.
I won't allow the creation of "fix" or "feature branches" or personal dev branches in the "origin" remote repository. That is something the devs should keep on their local machine(s). If they must keep two machines in sync with each other then they can reference each other as Git remotes, or use a Raspberry PI or network storage in the middle. That's easy to set up using git. But pushing those non-standard / non-approved branches to origin would be rejected by Phabricator.
Essentially the Phabricator-controlled repo would only allow one or two main branches (e.g. master and develop, something that is latest stable and the other with latest reviewed changes).
Phabricator encourages to use a strict code review process using a tool called "Differential". Only reviewed and approved changes are merged as a squash-commit into the main development branch. It's a bit radical, because it gets rid of in-between commit history... but maybe it also makes the overall commit history more readable, since each code review should have a meaningful description, test plan, assigned reviewers etc.
None of my branches live very long (and it's not how we track things back from JIRA tickets) so I tend to name them whatever will help me remember what they are for the few days they are alive :)
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#issueformat 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 (#issueformat).Referencing an issue number is such a great practice, but I usually forget. I just try to be as semantic as I can:
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:
We use issue numbers a lot when we talk in the team, so when I want to checkout a branch, I just do
git checkoutthe issue number andtabtab.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.
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.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
I like the key word prepended to the id of the issue! Very clean way to sort branches :)
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.