如何解决 monorepo 中的合并冲突？

Question

Assume the following situation:

• the monorepo contains two artifacts in separate folders, say frontend and backend
• frontend developers are not capable of solving merge conflicts in backend code
• backend developers are not capable of solving merge conflicts in frontend code
• feature-branch based workflow where frontend and backend developers work in parallel on the same feature branch

The problem arises when changes (created by separate developers) on a feature branch conflict in both, backend and frontend code. A single developer (given the mentioned assumptions) is not able to conduct an update-merge on his own.

What is the best practice to resolve merge conflicts which span frontend and backend code? If the vertical feature-branch based workflow is the underlying problem, how would you improve this setup while sticking with the first three assumptions?

Answer 1

Here is a blunt, technical way to split the merge conflict resolution in two distinct parts :

1. from the master branch, create two phony commits, one which carries only the changes on backend , one which carries only the changes on frontend

2. have two developpers merge each branch into feature

3. merge feature into master

---

1. split the changes in two :

# starting situation :
*--X--*--*--Z <- master      # X is the fork point
    \                        # Z is the tip of branch master
     \
      *--*--*--T <- feature   # T is the tip of branch feature

Run the following commands :

# from master, create a phony branch for backend :
$ git checkout -b backend master
$ git checkout X -- frontend/   # reset the content of 'frontend/' to its state in commit X 
$ git commit

# similarly for fontend :
$ git checkout -b frontend master
$ git checkout X -- backend/
$ git commit

You now have :

*--X--*--*--Z------
    \           \  \
     \           B  F  # B: tip of backend, F: tip of frontend
      \
       *--*--*--T

2. merge the two parts in feature :

$ git checkout feature
# have one developper fix conflicts on :
$ git merge backend
# and a second one on :
$ git merge frontend

Note : the merges can happen in any order.

The situation is now :

*--X--*--*--Z------
    \           \  \
     \           B  F
      \           \  \
       *--*--*--T--*--M <- feature

3. you can now merge feature into master

---

As for your workflows, if work on backend and frontend should be handled separately, you need to have some rule to reflect this in the branches managed by your developpers.

@bk2204 gives some directions towards doing this in his answer : keep work on backend separate from work on frontend, merge ASAP.

Answer 2

There are a couple typical approaches to this problem:

• Merge changes frequently and use a feature-flagging system so that new changes can be integrated without becoming active. This lets individual developers work on different aspects of a feature and merge it incrementally, so a feature branch is limited to a single or a small number of developers who are capable of resolving conflicts individually.
• Make feature branches operate as a combination of individual developers' feature branches, and force developers to each rebase their own changes, resolving conflicts, and then re-integrate those individual developer branches back into the feature branch.
• Have developers from each of the areas pair together to work on conflict resolution.

I've personally experienced the first and last of these, and I prefer the former, but depending on your workflow, it may not be possible. For example, if you have multiple lines of development (eg, a maintenance and a development branch), the first solution won't solve all your problems, but it may reduce them.

Generally, the more you can design your workflow such that the conflicts a developer has to solve are related to code they themselves are working on, the more successful you'll be. Even if other developers in the same area are capable of resolving conflicts there, the developer working on a piece of code will be able to do it faster and be more likely to do it correctly because they're presently working there.

A possible technical approach is using git imerge and stashing the incremental products somewhere as a ref, then having each developer resume the stashed state. This is likely to be tricky, though, and while possible, isn't recommended.