git show --no-patch --format=%f [<commit>]
Ticket link should always be included in PR description.
But branch names should be descriptive like terraform_dev_create_instance
etc
[feature/bug]/ISSUE-NUMBER-summary-of-issue
bug/psi-456-broken-args-parsingWith GitHub setup properly, on PR open, it auto comments the link to the ticket and links to the pr in the ticket.
1) Cmd + shift + . -> Copy branch name
2) Build feature on that branch name
3) Build / Merge on Github and Linear closes the issue
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.
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.
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.
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.
Hopefully the commits are already squashed and rebased before review to value reviewers' time.
This reaction tells me a lot about the state of our industry. (Or just the state of my mind.)
``` issues/{username}/{issue-number}-{description} ```
The username prefix is helpful, for both organization, and locating branches.
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
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.
I have not gotten there yet though
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
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.
pat_erichsen•3mo ago
ytreister•3mo ago
Also many people do not have the luxury of using Linear, many companies force developers to use Jira...