I have a script project I've been managing with Git. Besides two main branches, several minor branches have been introduced over time to cover minor features, tweaks or temporary changes. Some of these branches are nearing end-of-life, and I won't be updating them any more.

What's the different philosophies for handling branches like this? Should they be removed, or left in the repository unmaintained? If I do, won't I end up with a cluttered repository?

  • I should have mentioned, some of these branches won't be merged because they're covering special cases that are no longer needed. – Jo-Herman Haugholt Jun 28 '11 at 13:07
  • Herman - That really(!) depends on the user. For example, I used to keep those when I was working on some projects. I had a different branch for each project (asa a matter of fact, still do :) because some programs needed to be modified on a case by case basis. And I never know when I'm going to stumble onto a similar case again. Disk space is cheap nowadays. – Rook Jun 28 '11 at 14:04

Of course, this depends on the user and practices followed, but branches are usually deleted after merging.

git branch -d branchname

For example, after the following merge, you would delete the branch iss53, as you don't need to develop from that branch anymore. You can later recreate it at any moment using the sha1 value of the commit by git checkout -b <name> <sha1>.

alt text

  • 3
    If you already merged them, why use -D and risk deleting branch that, after all, has not been merged yet? -d would suffice, right? – Piotr Kalinowski Jun 28 '11 at 15:13
  • @Piotr Kalinowski - I don't know. Guess I was doing something at the time, and it slipped in without me thinking. Thanks for pointing it out! – Rook Jun 28 '11 at 19:31
  • 1
    Note that deleting a branch in git only removes the branch label and it's associated history. But the commits are still intact. In fact, if you've accidentally removed all the branches you can still find the "dangling" commits again. – Spoike Jun 28 '11 at 20:10
  • @Spoike - Of course. I would never want to delete commits, even if they were failed ones (idea-wise). I never know when I might need something from them again. Besides, by that logic, one might just "live" off the latest commit. – Rook Jun 28 '11 at 21:19

Personally I delete a branch once it is no longer needed. As long as all of its commits have been merged into other still existing branches, there is no harm in deleting it. If you want you can create a tag on that branch before you delete it so you can more easily recreate the branch if you ever need it again.


Delete the branch when:

  • A merge has been made into master/whatever.
  • Your little experiment (where you thought you could do something really smart) goes wrong.

I don't ever leave old branches lying around. Unless I'm positive that I'm going to go back and use a branch, it gets trashed after a few days of disuse. If I suspect that I may want to go back to a branch at some future point, I tag the commit and delete the branch.

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.