If your team’s Git branches look anything like this:
fixstuff
jon-branch
1234
testing123
final-FINAL
and you’ve wished your team’s branches were consistently named and made it clear who created them and why…
I built gibr to solve exactly that.
Check out the repo: https://github.com/ytreister/gibr
🧩 What is gibr?
gibr is a small command-line tool that automatically creates clean, consistent, descriptive Git branch names by pulling metadata from your issue tracker.
No more manually typing branch names.
No more deciding between feature/123-add-user vs feat/add-user-123
Just run:
gibr 123
and it will create a branch like:
ENG-123-add-user-search
Branch name is customizable via the .gibrconfig template.
Or you can use the Git alias:
git create 123
You can set that up with gibr alias command
🔌 Supported issue trackers
gibr currently integrates with:
- GitHub
- GitLab
- Jira
- Azure DevOps
- Linear
- Monday.dev
It fetches the issue title, type, and assignee, then generates a branch based on your configuration settings.
🛠 Initial setup
Run the interactive initializer:
gibr init
This will create a .gibrconfig file in your project root which is how gibr knows which issue tracker, project, your team's preferred naming conventions, etc. Setup is a breeze:
$ gibr init
Welcome to gibr setup! Let’s get you started 🚀
Which issue tracker do you use?
1. AzureDevOps
2. GitHub
3. GitLab
4. Jira
5. Linear
6. Monday.dev
7. Forgejo (coming soon)
8. YouTrack (coming soon)
Select a number (1, 2, 3, 4, 5, 6, 7, 8) [1]: 2
GitHub selected.
GitHub repository (e.g. user/repo): ytreister/gibr
Environment variable for your GitHub token [GITHUB_TOKEN]:
🎉 Found GitHub token in environment (GITHUB_TOKEN)
.gibrconfig already exists. Overwrite? [y/N]: y
✅ Created .gibrconfig with GitHub settings
You're all set! Try: `gibr issues`
🎯 Why I built this
I worked at a company where we used Gitlab for our repository, but Jira for issue tracking. I wanted to reduce as much friction as I could with creating branches, changing issue status, linking issues to Gitlab (branches and merge requests). I built a tool at my company specifically to automate all of this. When I left the company, I decided to rewrite the tool, but in a more plugin-oriented fashion to support any number of issue trackers, not just Jira.
🛠 How it works
You run:
gibr <issue-number>
It:
- Determines which issue tracker to use based on your configuration
- Fetches the issue and its metadata via API
- Determines the branch name based on your configuration and the issue metadata
- Creates + checks out the branch
- Optionally pushes it
- All fully configurable.
🧠 Multiple branches for the same issue
What if you started working an issue in a branch, and wanted to start over without deleting your existing branch? What if you just merged a branch, and realized you forgot one small thing and you want to create a quick follow-up branch based on your issue you just merged? gibr reduces the friction in doing this!
$ gibr issues
| Issue | Type | Title | Assignee |
|---------|--------|-----------------------------------------|------------|
| 50 | issue | Add support for YouTrack | |
| 44 | issue | Add support for Forgejo | |
| 39 | issue | Add dry run flag | |
| 38 | issue | Add support for issue types from labels | |
$ gibr 39
Generating branch name for issue #39: Add dry run flag
Branch name: 39-add-dry-run-flag
⚠️ Branch '39-add-dry-run-flag' already exists locally.
Would you like to create a new branch with a suffix? [Y/n]: Y
Enter suffix [take2]: take2
ℹ️ Creating new branch '39-add-dry-run-flag-take2' instead.
✅ Created branch '39-add-dry-run-flag-take2' from main.
✅ Checked out branch: 39-add-dry-run-flag-take2
✅ Pushed branch '39-add-dry-run-flag-take2' to origin.
📦 Try it out
Install:
pip install gibr
# or if you use uv:
uv tool install gibr
# install optional tracker extras if needed:
pip install gibr[github,jira]
# or
uv tool install --with github --with jira gibr
💬 Looking for feedback
I'd love to hear:
- Does consistent branch naming matter for your team?
- Does your team use different systems for repo vs issue tracking?
- Would you be interested in seeing gibr automate more than just naming, creating and pushing branches? Think pull requests, merge requests, changing issue status, auto-assigning unassigned issues that you start working with gibr, etc.
- Any pain points you'd like gibr to solve?
- Any issue trackers you'd like supported?
Thanks for reading — happy to answer questions!
Top comments (1)
Would love to hear your feedback here :-)