24

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?

0
32

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.

2

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.

1
  • 3
    Yes, I do know this. The history I am talking about is dedicated branch history - it is much easier to determine the timeline for something when it is its own branch.
    – Codeman
    Aug 6 '13 at 18:21
1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.