A common problem in my very small team workflow is handling merges from trunk/stable repositories up to feature branches which are ahead of the trunk or stable versions, but which need to track the changes in the trunk and stable versions. We are using mercurial, but any DVCS would perhaps have a similar workflow, including Git, or others.

Originally we had a workflow where a senior developer (me) did most of the merging, as that was the model I had experienced at a previous workplace, but similar to the previous place where we worked like that, this put a lot of burden on one developer to take the results of a large number of commits, and clean up the resulting mess.

If you were merging one change, with one commit message, maybe you could do this cleanly, but what often happens to me, is that I get a little behind, and a week of changes needs to be merged.

What I'm wondering is, when you DO get into a situation where a large merge is necessary, using Mercurial or DVCS, what is the process that you use, and does it involve collaboration between multiple developers on the team, and does your team use pair programming to solve this complex programming problem of How Do I Sort Out and Land the Changes from TRUNK that need to get to FEATUREXYZ branch.

enter image description here

The workflow or standard-practice I am envisioning looks like this:

  • when a merge up to a feature branch looks easy and only involves my own changes I do it on my own

  • when a merge up to a feature branch also pulls in someone else's changes that are not trivial, I involve that person in the merge.

Common sense? I think so. But I suspect that others have been down this road and can offer a more clearly elaborated, and "tried and true" approach for this general situation.

  • IMO you should not merge trunk into a feature branch, as then it will be just random garbage. Rather consolidate and rebase on top. Or leave alone and merge merge back ASAP.
    – Balog Pal
    Commented Jun 5, 2013 at 15:14
  • Why do you need to merge from trunk to a branch? Maybe the problem is in that process.
    – Andy
    Commented Jun 5, 2013 at 15:34
  • Well, long lived feature branches.
    – Warren P
    Commented Jun 6, 2013 at 12:46

2 Answers 2


There really is no easy way around it. A fundamental truth about version control is the longer you diverge, the harder the merge. (I should put that on a T-shirt).

There's no reason every team member needs to be involved in the merge every time, but you can rotate it around. If you can't do it one day, make sure someone else does. The more your team is involved, the more they will be aware of incompatibilities growing between the branches, and the less likely they will be to make breaking changes.

You should also look for opportunities to merge into the trunk. You should break long features into intermediate steps that can be safely tested and merged in, even if the entire feature isn't available yet. New features usually require both rework of old code and creation of brand new code. It's the former that creates the most merge conflicts. Luckily, it's also the easiest to change before a feature is complete.

For example, say your new feature requires a certain field of a widely-used existing data structure to be 16 bits instead of 8. You can usually make a change like that in the trunk without adversely affecting existing code. The sooner you do so, the sooner the rest of the company will stop making that particular merge conflict in their new code.

In other words, if you're continually fighting the same kinds of merge conflicts, you should look for ways to fix it in the trunk, if at all possible.

  • Sharing the task is very good advice, rotating or something.
    – Warren P
    Commented Jun 7, 2013 at 13:12

It somehow sounds going backwards.

The feature branch is owned by one or more people. They know what is it all about. They shall manage its state by whatever means convenient.

The branch will be integrated at some moment, the devs may leave it to the final sate or chose to reduce divergence. In any case it semantically looks like they add their changes to whatever point on trunk.

Ideally the rebase (or merge) just succeeds, the branch compiles, tests work, all happy. If it's not the case, again the branch people will go discovering what happened on main, either just looking at history or grabbing trunk devs for info. (The good feature of DVCS is the action can be postponed without hindering work...)

Using PP or reviews to look merge impact? if the delta is non-trivial, sure, why not. But if testing framework is in place it's supposed to catch problems in time before final integration.

  • We have very long lived feature branches, that are refactoring or rebuilding some legacy area of the code.
    – Warren P
    Commented Jun 5, 2013 at 23:55
  • Care to explain what is the benefit? To me sounds like a waste generator matching halfdozen categories. (No pun, really curious)
    – Balog Pal
    Commented Jun 6, 2013 at 1:26
  • Refactoring a legacy codebase. some tasks take months to complete. Meanwhile, you can still release ongoing progress (smaller fixes and cleanups) in the trunk. The downside is this merge problem. I think part of our merge problem is that Mercurial's non-context-aware merge/diff strategies are unequal to this task.
    – Warren P
    Commented Jun 6, 2013 at 12:45
  • We use git, and I make massive refactorings over the ~1.5MLOC codebase, and it works fair. IMO 2 month away is excessive, even 1 is, I'd suggest to seek smaller steps that can be integrated often (max 2-3 weeks away). If it's really refactoring, not changing behavior there just must exist a way, ?
    – Balog Pal
    Commented Jun 6, 2013 at 13:00
  • Yes minimizing the time between trunk Dev and side branch megre up appears key.
    – Warren P
    Commented Jun 7, 2013 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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