We have several bugfix branches that are starting to pile up. They have been merged into master, and deployed to production.
Is there a good benchmark for when these branches should be cleaned up?
Should they ever be cleaned up, or is it good to have the historical data?
The way git works is that a branch name is just a pointer to a specific commit. Once you merge a hotfix branch into master, your hotfix and master will point to exactly the same place in the commit tree. As you make more commits on master, the hotfix branch will continue pointing at the same place while master will get updated. Your history will always be preserved.
So basically the only reason to keep hotfix branch after a merge is if you plan to make any more changes to the same hotfix, which doesn't make much sense once you release the hotfix. So you should feel perfectly safe deleting the branch after the merge.
One more thing you could do though, is once the hotfix is merged, create a tag on the master branch identifying that point as the hotfix release.
If it's merged into master, then deleting the branch won't delete the history. You can always recreate the branch again later from the last commit before the merge.
I would suggest that all PR’s be followed by a delete. There’s no reason to hang onto a dead branch, Everything that you need to know is now contained within master.
The need for having an easy to access branch for looking at the history of the feature, should be wrapped up with the PR. Basically you need it for a good code review, but that is exactly what PR should be. The only reason to maintain it, would be because you expect some trouble with it, and think maintaining the branch is going to be the easiest way to get back in and fix up whatever problems crop up. But (a) that probably isn’t true and (b) even if it was, you need to pull in all of the other changes as well that happened prior to the PR as they could be the source of your problem. Looking for a solution to a problem in a partial reproduction of the code is likely to cause more problems than it solves. Only if you can be positive that a problem is isolated from the rest of your code base, should you even consider using a stake branch to find and fix it.
You should delete these branches before their mere existence slows you down, and before you have forgotten what they are used for.
Another thing are abandoned branches. You branched for something, but at some point it will be more work rescuing whatever useful is in there, and merging it with the latest version, then doing the work again.
Immediately after merging.
Branches are cheap in Git, and if you're keeping them around, you could be stuck in the SVN/CVS era. If you made a merge commit, it often contains the branch name. Even with fast-forward merges, branches shouldn't really be used to track historical data. That's what commit messages are for.
We often add the bug tracker ticket number to the commit message so that it can be referenced in the future. The branch pointer and its name are redundant in this case.
In fact, you can check out the repository with no other branch except the main one, and it would still contain all commit messages. That is the historical data. You can easily create any branch again at any commit you like, and you can change any branch information any time. But you mostly cannot alter the commit history without serious consequences.
