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...
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 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 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.
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.
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.
20 comments
[ 3.6 ms ] story [ 46.5 ms ] threadAlso many people do not have the luxury of using Linear, many companies force developers to use Jira...
https://crespo.business/posts/overeng-pr-create-jj/
git show --no-patch --format=%f [<commit>]
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.
https://github.com/ytreister/gibr/issues/42
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 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.