This question already has an answer here:

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?

marked as duplicate by Jimmy Hoffa, BЈовић, gnat, Kilian Foth, GlenH7 Aug 8 '13 at 11:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


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.

  • 1
    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.