Git CLI tool for intelligently creating branch names

27•Terretta•7h ago

Comments

pat_erichsen•6h ago

Neat! Linear does this really well with a few different configurable patterns.

dcre•6h ago

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.

https://crespo.business/posts/overeng-pr-create-jj/

davelee•6h ago

I use the `%f` format option. I have a `bn` alias ("branch name"):

git show --no-patch --format=%f [<commit>]

r1cka•6h ago

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.

morkalork•6h ago

Yes, please just name the branch after the ticket/issue number so we can all get the context for it and call it a day

wara23arish•5h ago

I hate issue numbers for branch names. ISSUE-9482 doesn’t really provide much.

Ticket link should always be included in PR description.

But branch names should be descriptive like terraform_dev_create_instance

etc

6LLvveMx2koXfwn•5h ago

we do:

  [feature/bug]/ISSUE-NUMBER-summary-of-issue

e.g.:

  bug/psi-456-broken-args-parsing

darkwater•5h ago

More or less the same here, but we (I?) prefix it with the username as well, so when pulling branches you know who created it.

celticninja•4h ago

But the PR and git blame can tell you this so I would never look at the Branch name to find out this information

darkwater•2h ago

For me is useful when I run 'git fetch' from the command line. I don't use any graphical git client

dewey•3h ago

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.

jjgreen•5h ago

I've worked in a couple of places with <issue ID>-<something descriptive> conventions, moderately useful

krferriter•5h ago

Yes, `issue-10-add-feature-X` style is best.

bavent•3h ago

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.

johntash•2h ago

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.

jasonjmcghee•5h ago

This. Linear has the one click or shortcut to grab the generated branch name based on the ticket.

With GitHub setup properly, on PR open, it auto comments the link to the ticket and links to the pr in the ticket.

dewey•3h ago

This is probably my favorite Linear feature.

1) Cmd + shift + . -> Copy branch name

2) Build feature on that branch name

3) Build / Merge on Github and Linear closes the issue

aizk•5h ago

Great point

alkonaut•5h ago

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...

delusional•3h ago

Either it has commits I care about or it doesn't. Either way, I'm not going to consult the branch name.

If it has commits I care about, then it stays. If it doesn't, It goes. I'm only deleting on the server afterall, people can just push it back.

loevborg•4h ago

Correct, I use uuids as branch names, to the chagrin of my teammates

brettgriffin•2h ago

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?

focom•3h ago

Commit message should be ephemeral too. Squashing after a PR should be the default. Only at that moment does the PR/Commit message matter.

bavent•3h ago

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.

freedomben•3h ago

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.

bavent•2h ago

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.

danielbln•2h ago

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.

bavent•2h ago

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.

focom•26m ago

> If you keep your PRs small

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.

focom•27m ago

> 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.

You downvote me but you just agreed with me. When was the last time you read individual commits of a PR? If your PR need to keep the history of the commits that means that you should split your PR into smaller one.

teiferer•5h ago

I was so afraid that this is another "look I built sth that uses AI!" post, slopped together in an afternoon. I'm glad it's not, such a relief!

This reaction tells me a lot about the state of our industry. (Or just the state of my mind.)

roflchoppa•5h ago

a format that as worked well for me (and that I've brought with me to other teams)

``` issues/{username}/{issue-number}-{description} ```

The username prefix is helpful, for both organization, and locating branches.

compilethread•5h ago

Simple and clear branch names make teamwork so much easier.

celticninja•4h ago

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.

spencera•4h ago

I think in 2025 "intelligently creating" kind of implies the use of AI but (thankfully) this is just doing a string format based on an issue title.

paradox460•23m ago

I rarely make named branches these days. Just use JJ git push -c, which creates a branch name based off the change I'm pushing

A Survey of Internet Censorship and Its Measurement

The sustainable, repairable Fairphone 6 is now available in the US for $899

HN: AI File Sorter auto-organizes files using local AI (Windows, macOS binaries)

Scheme Name: Calculator

Systems Don't Exist but Definitions Do

Linux – Sizecoding

Show HN: Artle - a daily art guessing game

What's New in Shortcuts for the Apple OS 26 Releases

Platform to Show Proof of Work

CRISPR anti-tag-mediated room-temperature RNA detection using CRISPR/Cas13a

Somatic hypermutation articles from across Nature Portfolio

Show HN: I built a self-hosted error tracker in Rails

European Land Use Visualization

Government Urges Total Ban of Our Most Popular Wi-Fi Router

Waymo acknowledges its vehicle hit a San Francisco corner store cat

Mathesar 0.7.0 released with CSV imports, file uploads and PostgreSQL 18 support

Agents Rule of Two: A Practical Approach to AI Agent Security

Latter-day Saints are having fewer children. Church officials are taking note

To Affinity and Beyond

My first fifteen compilers (2019)

Take-Home Exercises

NASA is sinking its flagship science center during the government shutdown

Making EVs takes big energy, but after 2 years, they're cleaner than gas cars

Judge sanctions Tesla for 'willful' and 'deliberate' violations in crash lawsuit

DoubleSpeed – Automating Attention

Zoho Founder on Arattai's Rise and More – Sridhar Vembu

A theoretical way to circumvent Android developer verification

Handling spam on my humble contact form

Scientists pinpoint when humans had babies with Neanderthals

GBrain Therapy Chatbot