3

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?

Improve this question
2
  • I should have mentioned, some of these branches won't be merged because they're covering special cases that are no longer needed. Commented Jun 28, 2011 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. Commented Jun 28, 2011 at 14:04

4 Answers 4

Reset to default
9

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

Improve this answer
4
  • 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? Commented Jun 28, 2011 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! Commented Jun 28, 2011 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. Commented Jun 28, 2011 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. Commented Jun 28, 2011 at 21:19
6

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.

Improve this answer
2

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.
Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.