Should developers merge code across branches?

Question

Currently we have 3 branches and trunk. If a developer makes a change in one branch, they alone are responsible from merging that change to the 3 other branches and eventually back to trunk. There's a published chart on the merge order that gets updated periodically.

So, we have lots of little merges happening across branches.

In the past, we have had one person cut branches and do merging back, mainly from branch to trunk. If there is a conflict, the 2 or 3 developers who caused the file conflict would resolve it. The branch and merging strategy was handled by an individual and mainly involved bring branches back to trunk.

Is having individual developers merge typical? Or should it be handled by one person and coordinated at specific intervals to manage the branches?

Answer 1

What concerns me here is that you make it sound like anyone checking in code has to blindly check it in to multiple branches. That is wrong. Branches should exist for a reason. The event of checking in code should happen once and flow from there. Who gets it flowing isn't as important as that branches are kept meaningful and useful in each step.

It sounds to me like you had a better approach in the past. The question then is: why did that change?

Answer 2

Requiring a developer to merge their code into 3+ active branches could be a significant productivity drain.

Plus, trusting an entire team to be perfect with their merges is a ticking time bomb. It could introduce (or reintroduce from older source) bugs if the developer is not careful with their merge.

One of the better approaches that I have worked with is task based branches. When a task is assigned, the developer checks out the current the Staging Branch and creates a new task branch (with the name of branch as the task number). The developer is not responsible for merging with other branches, other than possibly the Staging branch once they are finished with development. Production and/or Versioning branch merges are handled separately... and the task branch is only merged into Production/Version branches after passing UAT.

Answer 3

When you create a branch, you are responsible for merging it back into development. (Actually, you merge development into your branch and fix all the problems, then there should be a code review, then you build a version for testing, when it's accepted by test you merge the development branch into your code again, and then you merge it into development without conflicts).

Everyone knows that they are not the only ones working on a project. So they all expect that development will be changed by the time they want to merge their changes to development. They know what they are doing, so they merge development into their branch and are responsible for it.

Some people apparently don't like testing a branch. Well, I don't like merging untested code into the development branch and then testing it and finding it is broken. Because meanwhile someone branched from the development branch and is wondering why their code doesn't work - because someone broke it before they even started working.

Answer 4

That's definitely what stands out to me - that you are merging everything into everything. Why? Much more standard is to have one integration branch, and merge individual feature branches into that. Does it point to architectural problems with the code - i.e. there's a lack of separation of concerns?

At what point in your process does code review happen? Do you do any code review prior to merge into trunk? What about code review before merging across branches, in your process?

It doesn't really matter too much who does the merging, as long as you have a consistent process. Merging is fairly routine when it goes smoothly. Clearly it makes more sense usually for the person/people who wrote the code to resolve any conflicts with it. Merge conflicts should be rare. If you are experiencing merge conflicts too often, then it means your branches are not independent enough and/or you are letting them run too long.

Answer 5

Are you trying to run a code tree or a code lattice?

Trees are less complex than lattices.

Sometimes things can go a little quirky with a merge and you have to get it sorted manually. These quirks come up more often with lattices, and are harder to figure out. If you are not careful you can end up with things like circular merges (which confuse some automated tools) and merges that end up taking or depending on code that is not the newest.

You can run your code repository any way you want, but I recommend sticking with a tree if you can.

If you think your devs would have trouble figuring out the difference, then yes, I would recommend you train up someone to be the SCM admin.

Answer 6

I have seen it work where the branches were strictly hierarchical, that is one is expected to be more stable than the last and any fixes that go into the more stable branch should get merged into all upstream branches.

Individual developers are responsible for forward merges while a periodic task does the reverse merge. The task after merging locally runs the build+unit tests and commits on success. If there is a conflict that can't be auto-resolved or build/test fail, the developer with the last commit is responsible to unblock the process.

The task should run frequently enough (few hours to max daily) so that the upstream branches always super set of downstream, there by avoiding too many conflicts in auto-merge.

Answer 7

You definitely should not be merging your changes into someone else's branch. The reason for working in a branch is to have an isolated environment.

If you make changes in the branch you are working on, then notice some undesirable behaviour in the compiled application, you need to able to figure out which of your changes caused the application to break. If other developers have merged their changes into your branch, any of their changes could be causing the problem, but you don't know all the details of what they changed, and you could waste time tracking down an issue that the other developer has already found and fixed.

In my dev team we create a 'platform' branch for each sprint, then branch off it for each story. When stories are complete we merge them into an 'integration' branch. Refactoring changes are done in the 'platform' branch and communicated to other developers who merge these changes into their story branches when they are ready.

This works well because:

1. Each developer is in control of the code they are working on, only incorporating refactoring by other developers when it's a good time for them.
2. There is an 'integration' branch containing all the completed stories that the QA team can test during the sprint.
3. At the end of the sprint we can merge the 'platform' branch and the story branches for accepted stories into 'master', leaving out incomplete or unaccepted stories from the next release candidate.
4. Merging stories is easy with few conflicts because refactoring changes with widespread impact are done in the 'platform' branch and are already merged into each story.

You should think carefully about what you are trying to achieve and design a branching/merging scheme that helps you to achieve that. Don't be a slave to the tools, make the tools work for you.

Answer 8

Disclaimer: I mainly use Git nowadays, and we release our product (in contrast to projects) once a year. So, this might be slightly biased.

We use branches in two cases. Feature branches are created and maintained by individual developers. They can be shared, but usually the creator merges it back on the main development branch after the feature is implemented. The other type of branch is what we call release branches. Those are created as forks from the development branch and solely exist to implement hot fixes. Those branches never merge back again or receive a merge from other branches. Fixes travel by Cherry-picks only. The developer that implemented the fix is responsible to do that.

Those are also the two most sensible uses of branches I can think of. Most likely you have a different development cycle and needs, but I think you would still benefit from a similar approach.

That said, there are, of course, other workflows, which use branches in still a different manner ([1] [2]). You might want to have a look at those, too.

One last thing: if you want to make heavy use of branches, first choose an SCM with light weight branches. I let you guess which particular one I have in mind.