Skip to content
Dec 7 2008

Should Branch History Be Kept After a Merge?

As we’ve changed our development process to now work in feature teams and feature branches (much more on that in a later post), one of the things we’re discussing is whether or not to keep the branch history once a branch has been merged back into trunk.

Initially, we thought of course we’d want to keep the branch history. Check-in history and revision comments are very important to us and that seemed like the obvious decision. However, we’re now having second thoughts and are questioning whether or not the branch history even matters once it’s merged into trunk.

Our thinking is that first and foremost, trunk rules all. Trunk is the mainline and should be kept sacred and *always* in a good working state; afterall, we ship trunk. A branch is a segment of work with specific functionality for a certain amount of time that, when completed and merged into trunk, goes away. Obviously history of trunk is extremely important, but should you really care about all the incremental changes that occurred in a branch before the merge occurred? We’re beginning to think not.

So I wanted to ask the question and get feedback from you: should branch history be kept after a merge? Whether your answer is yes or no, I’d also like to see your reasoning in case we’re missing something. Start/join the discussion by leaving your comments.

Similar Posts:

Filed under Uncategorized
  • http://michaeleatonconsulting.com/blog Michael Eaton

    I’ve been wondering the same thing and am coming to the same conclusion as you. Once it’s in trunk, I’m not sure I see the point of keeping it around.

    On the other hand, I still haven’t cleaned out my branches either. ;-) It’s a tough call becaues I hate to lose the history.

    I might consider giving it a certain period of time…say a couple weeks to a month after the merge before I nuke the branch.

  • http://chadmyers.lostechies.com Chad Myers

    I’m thinking "No, don’t keep it", but my inner pack-rat won’t let me let it go. Maybe you can archive it or something?

  • http://devlicio.us/blogs/derik_whittaker Derik Whittaker

    Funny, we are having the same conversation at work. At first glance I said yes at first. Then if you step back and take a look you have to ask ‘do i care about the in progress check ins’?

    I still say yes. My reason is simple. If you do not bring over your comments then you can never get them (assuming you delete the branch after the merge) but if you bring the comments over you can have them if needed.

    Either way there is no wrong choice.

  • http://community.hydrussoftware.com/blogs/jeffesp/ Jeff Espenschied

    I think that it depends on the granularity of your branches. At my last job, we had long running large feature branches (e.g. add support for WPA into wireless router software) and keeping the history was useful when triaging a bug. That branch might have lived for 3 months and had other branches off of it for iterations. If your branches are more in line with one iteration, then you might not need to care about all the intermediate checkins. I still don’t like losing the commit messages, but I am a pack-rat by nature and would keep everything at the expense of organization.

  • http://simpable.com Scott Watermasysk

    Delete it. The phrase "I might need it later" is pure evil. Kill it. Kill it. Kill it. :)

  • http://ericmatz.net Eric Matz

    I would want that stuff around. Those comments may provide good insight into situations like "who the !#@$ coded this?" or "why the !$#% did this developer who quit 5 years ago decide this was a good idea?" – merges don’t necessarily provide that granularity. Do those questions come up often enough to keep that history around for easy viewing? Probably not. I’d come up with some type of archiving strategy, though.