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?

  • 1
    The duplicate is wrong. This one is a completely different from another one. Duplicate notice should be deleted as it just confuses people. – FreeLightman Feb 2 at 9:53
  • 1
    I voted to reopen. – Codeman Feb 3 at 10:02

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.

| improve this answer | |

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.

| improve this answer | |
  • 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

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