At my place of employment we use Jira ticket numbers in our git branches so that we can take advantage of the ticket-to-code-linking magic.
But as a projects grows, the number of remote branches gets kind of insane. I suppose this doesn't affect performance or anything. It's just a little unsightly and makes it difficult when you need to go hunting for remote branches.
What are best practices here?
Delete local branches and keep the remotes?
Delete remote branches and lose the Jira link on historical tickets?
Top comments (8)
Hey,
good question!
I've been working on big repo for years now.
This is a strategy that works. I'm not saying it's the best one but it works and scale.
Everybody fork the main repo and no commit / branch creation is allowed on the main repo.
Dev create a branch on his own repo, then he create a pull request on main repo.
In GitLab/ GitHub, you have an option to delete the branch when PR is merged.
Then from time to time you can run
git fetch -pto clean up your local repo. On you repository, there's usually a button to remove merged branches. You can also manually remove old branches (i.e. latest commit > 60 days).For this, I couldn't agree more with @cescquintero . You can link the ticket number to the commit message ;)
Thanks for sharing!! This is exactly what I needed.
--prune
After fetching, remove any remote tracking branches which no longer exist on the remote.
As a general rule, delete them completely, but embed the relevant info in the commits (either the merge commit if you use one, or the commits of the branch itself if you don't) to link things to your issue tracker (see for example how GitHub handles lines of the form
Fixes: #XXXXin commits, when the commit is merged the referenced issue is closed and retains a link to the commit that closed it).Having too many branches actually has a negative impact on git performance (it's not much unless you have really crappy storage (or are stuck using WSL1), but it's there) and repository size (bigger impact here), even aside from the issue of finding specific branches.
When it's a "topic branch" (some stuff/features that you want to develop outside of master but that are really part of the "main development branch") then as soon as the code review has been done and the branch has been merged to master I almost always delete both the remote and the local branch. I cant remember that I've ever missed them later on, besides the commits are still there anyway, and it just reduces a lot of useless clutter which isn't helpful in any way.
I've seen projects where they keep feature branches for a long long time. This is something called long-lived branches.
I personally don't like it. I prefer short-lived branches.
In that regard, the only branches I keep in the projects I've worked are the ones related to the flow of deployment:
Everything else is deleted whenever it's possible: right after merging or when cleaning the repo.
It all depends on what the team wants to do with branches. I've fortunate to always have a say in how to order branches in my teams and this is the way we go.
And also I'm a very organized person and seeing all those branches make me itch and just can't resist the urge to delete them 🤣🤣
The best practice would be:
This will make sure that:
Commit message should list relevant issues. In general this is a single issue. Some put the number in the summary, I stopped doing this, it is just better to search the history for a specific issue.
Do not keep merged branches around. It isn't worth it.
BTW, if in your commit you use the Jira story ID, then you'll never lose track of Jira <-> commit