Back to Home10/31/2025, 1:37:10 PM

Git CLI tool for intelligently creating branch names

Terretta

35 points

60 comments

Mood

supportive

Sentiment

positive

Discussion Activity

Very active discussion

First comment

55m

Peak period

Day 1

Avg / period

Comment distribution60 data points

Based on 60 loaded comments

Key moments

01Story posted
10/31/2025, 1:37:10 PM
19d ago
Step 01
02First comment
10/31/2025, 2:32:05 PM
55m after posting
Step 02
03Peak activity
39 comments in Day 1
Hottest window of the conversation
Step 03
04Latest activity
11/3/2025, 6:13:23 PM
15d ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (60 comments)

Showing 60 comments

pat_erichsen

18d ago

1 reply

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

ytreister

17d ago

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

davelee

18d ago

1 reply

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

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

ytreister

17d ago

Interesting idea, however, don't you first need to create the branch before you start committing commits?

r1cka

18d ago

5 replies

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

18d ago

3 replies

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

18d ago

3 replies

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

18d ago

2 replies

we do:

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

e.g.:

  bug/psi-456-broken-args-parsing

darkwater

18d ago

3 replies

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

18d ago

1 reply

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

18d ago

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

ytreister

17d ago

1 reply

I added a new TODO issue so that username can be configured in the branch name. gibr currently does not have support for username.

https://github.com/ytreister/gibr/issues/42

ytreister

16d ago

I implemented this in version 0.6.0 which was just released. https://github.com/ytreister/gibr/releases/tag/0.6.0 The issue assignee can be used in the branch name.

dewey

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

ytreister

17d ago

gibr makes it super easy to do exactly this!

jjgreen

18d ago

2 replies

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

krferriter

18d ago

1 reply

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

bavent

18d 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

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

ytreister

17d ago

gibr makes it easy to do this and in a consistent manner

jasonjmcghee

18d ago

1 reply

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

18d 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

ytreister

17d ago

That is what gibr does, it helps you do this with ease

alkonaut

18d ago

2 replies

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

18d ago

1 reply

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.

ytreister

17d ago

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.

ytreister

17d ago

Exactly, people tend to leave messes. It makes it much easier to know what the branch was for and have more piece of mind when you want to delete it.

loevborg

18d ago

2 replies

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

ytreister

17d ago

Why would you do this!!!!!

brettgriffin

18d 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

18d ago

2 replies

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

18d ago

2 replies

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

18d ago

1 reply

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

18d ago

2 replies

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

18d ago

1 reply

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

18d 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

18d ago

1 reply

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

bavent

18d ago

Right, small PRs are great. And they are even better with a nice commit history for me to follow. One does not exclude the other.

focom

18d ago

1 reply

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

bavent

18d ago

Calm down dude, I can’t even downvote people.

The last time I read individual commits of a PR? Maybe two hours ago. Before that, maybe five hours ago. Not everyone works like you do. Some people like clean commits. As I said, it’s very helpful when reviewing a PR, for me. I never said it was helpful for you.

xorcist

18d ago

Did you mean before the PR? Why would anyone have a review system if you change the code after review?

Hopefully the commits are already squashed and rebased before review to value reviewers' time.

aizk

18d ago

Great point

teiferer

18d ago

1 reply

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

ytreister

17d ago

I used some AI to help me, but I put in a lot of thought to how it is created. I have plans to add many more useful features over time.

roflchoppa

18d ago

1 reply

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.

ytreister

17d ago

1 reply

Unfortunately, gibr does not yet support username in the branch name, but I created an issue and hopefully can get it done very soon

https://github.com/ytreister/gibr/issues/42

ytreister

16d ago

I implemented this in version 0.6.0 which was just released. https://github.com/ytreister/gibr/releases/tag/0.6.0 The issue assignee can be used in the branch name.

In the future I want to allow a user to easily assign an issue to the current user if they use gibr with an unassigned issue

compilethread

18d ago

1 reply

Simple and clear branch names make teamwork so much easier.

ytreister

17d ago

Yes, I agree, and that is why I created this tool

celticninja

18d ago

1 reply

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.

ytreister

17d ago

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.

spencera

18d ago

1 reply

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.

ytreister

17d ago

I don't know why I did not think of that, but I can see how people would assume this nowadays!

paradox460

18d ago

1 reply

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

ytreister

17d ago

1 reply

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.

paradox460

17d ago

1 reply

We've done the same thing, but we only link JIRA tickets to PRs, so when I open a PR, I stick it in the PR description body.

ytreister

17d ago

1 reply

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 have not gotten there yet though

paradox460

15d ago

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.

https://github.com/paradox460/dotfiles/blob/main/dot_bin/exe... - This creates PRs based off a few different approaches, the -c flag lets you do nameless branches

https://github.com/paradox460/dotfiles/blob/main/dot_bin/exe... - is the one that would fetch tickets from JIRA and make new branches off of it

dcre

18d 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/

ytreister

17d ago

Hey everyone — I’m actually the author of gibr!

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.

View full discussion on Hacker News

ID: 45771843Type: storyLast synced: 11/19/2025, 1:03:11 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Read Article View on HN