How to resolve merge conflicts in a 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

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 (e.g., 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.