I think people worry too much about branch names. Feature branches are usually ephemeral. Prefix your branch with your personal identifier so I know who is primary on it and worry more about the commit message which will live on indefinitely.
I have a little script that does this automatically - lists out Jira tickets assigned to me, then when I select one, creates a branch with the ticket number and the title, subbing hyphens for spaces and truncating if needed. It’s handy for when I want to list branches, I can filter on keywords I remember from the ticket name.
That's been my preference at most places I've worked. issue id so the branch gets linked to jira or whatever and a short description to find the branch later if needed.
A nice benefit of prefixing by your-name/issue-1234-some-description is that many git clients will show it in a folder structure that way and it's easy to differentiate yours from other branches.
having feature/username/id-desc is good though. Because at least you can identify why the branch is there. That they are ephemeral doesn't mean that people actually clean them up...
I understand, but that means you need to review the commits and code changes and do not have the context which could be found either in the issue title, description, etc.
This would infuriate me. You have to index that guid to something yourself. Why wouldn't you at least give yourself some help (your name, issue number, type of change, area of project, etc). Why make your job harder than it needs to be?
Hard disagree here. GitHub does encourage this sort of thing, but even there for my PRs to be easily reviewable, I like to keep my commits organized and with good messages explaining things. That way the reviewer can walk the commits, and see why each thing was thing was done.
I also like it for myself, when I’m going over my own PRs before asking for a review - I will often amend commits to ensure the work is broken down correctly, each thing that should go together, does.
In a way, stacked PRs are just a higher-level abstraction of this too - same idea, keep work that goes together in the same place.
Fully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or implementing one feature. Obviously there are cases where this ideal isn't practical, but the answer is still not squash everything, it's to think for 10 more seconds about the commit and do your best.
Yeah, I think over use of GitHub, which seems to encourage squash-merging, has led to this where a lot of people I’ve seen treat a PR as essentially one commit - because it ends up being one in the end.
If you keep your PRs small I guess the end result is the same, but even then I like things in individual commits for ease of review.
I want to see detailed atomic commits during PR review, and once it's reviewed I'm happy to have it squashed. If the PR produces so much code/changes that main branch needs detailed atomic commits for future reference, then the PR was too large to begin with, imo.
I do agree that this is a good compromise. For me, if I do a git blame and eventually can find the PR that led to change, if it has nice clean commits, that’s good enough.
Its not a if. it's necessary for the sake of people reviewing your code.
Unless you work alone on your pet project and always push to master you never work alone.
Sounds similar to a short script I use to generate branch names with jj, which has the advantage that you don’t have to name a branch until after you’ve already written the code, so the LLM can name it based on the contents of the diff.
I think branch names are quite unimportant in development and often don't worry about them being too descriptive.
In my org it is common to use the JIRA ticket number in there somewhere but other than that I think you should leave it up to devs. I can't think of a reason why I would need to know the branch name.
My favorite branch name I created was for a JIRA ticket with the number 2468.
This became ab-2468-who-do-we-appreciate
Detailed branch naming conventions are just another piece of useless documentation for devs. And if you are using the branch name to tell you what is going on the you are misunderstanding the review process.
When you use Gitlab and squash your merge request, a new merge commit with the name of the branch is created, so I found it very helpful in that situation to know the name of the branch.
I just wanted to say thanks for all the comments and discussion. It’s been amazing (and honestly a bit surprising) to see so many developers checking it out.
The idea for gibr came from the frustration I had when I was forced to use Jira for issue tracking and GitLab for our repos. At the time, I built an internal tool called jig that integrated the two. With a single command, it could create a branch, push it, transition the Jira issue to In Progress, and open a merge request with everything pre-filled — assignee, reviewers, description, and so on. It became really popular at my company.
I decided to take that idea further and rebuild it as an open-source tool with a plugin architecture, so it could work with any issue tracker or Git provider, not just Jira and GitLab.
If anyone has feedback or ideas for new integrations, I’d love to hear them — some great suggestions have already come in that might make it into the next release.
Thanks again for the support — this community is awesome.
Interesting. That seems to work if your work is not associated with an issue tracker. Many use issue trackers and like to link each branch or PR/MR to an issue tracker.
OK, so it is possible that when the gibr pr command gets added that it could be helpful. My thought is for it to automate the creation of the PR and will contain the description which links to the Jira issue.
I was doing that for a while with some CLI scripts, never really melded them together, but I had one from before I started using JJ that would make a new git branch named off a JIRA ticket, and a newer one that wrapped up the various jj and github gh cli invocations to create a PR off a branch.
The jira cli util I used, go-jira, hasn't been updated to use the new Atlassian APIs, and I haven't spent too much time looking for a replacement.
I am not sure how configurable the button in Linear is. Also, gibr allows a user to not need to even leave their terminal to list their issues and create/push the branch. I also hope to have more features like creating a PR/MR and linking to a git repo.
Also many people do not have the luxury of using Linear, many companies force developers to use Jira...
