0

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. Problem illustration

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?

Michael Hoff
  • 6,119
  • 1
  • 14
  • 38
  • 2
    How are you generating conflicts that span the two directories? If the frontend devs are only working in the frontend directory, their changes *can't* conflict with changes in the backend directory, and vice versa. – jonrsharpe Aug 28 '20 at 09:32
  • Let's say we have two feature branches A and B. Both originate from the same commit on the develop branch. Both branches contain changes in backend *and* frontend. Now, after A has been merged into develop, you also want to merge B. For this, you need to update-merge B first. At this point, a conflict in both directories can arise. – Michael Hoff Aug 28 '20 at 11:00
  • Why not pair developers when dealing with these scenarios? Note that you have another issue: you can't tell until *after* the merge whether develop+A+B actually works, because you're merging develop+A and develop+B - rebasing B on top of develop+A might help, then the conflicts can be resolved commit-by-commit. All of this becomes easier when you integrate smaller changes more often. – jonrsharpe Aug 28 '20 at 11:07
  • I agree. Though, pairing developers is tricky right now, as the developers work in a remote setup and not necessarily at the same time. We try to keep changes limited in size, but it still happens sometimes. – Michael Hoff Aug 28 '20 at 12:07
  • Your situation about A and B branches would never happen if front-end developers work on front-end directories and back-end developers work on back-end directories. You would then have branches only containing changes to one set of those directories. How did branch A and B happen in the first place? Did you have both front-end and back-end developers contribute to a single branch? If so, wouldn't it be possible just involving the same developers when a conflict arises? – Lasse V. Karlsen Aug 30 '20 at 14:08
  • Yes, the assumption is that both developers contribute to the same feature branch. Remote work aside, the problem with involving both developers is that resolving backend conflicts is a task where frontend developers are not necessarily required and vice versa. Hence, they both need to collaborate on resolving conflicts on the update-merge while solving potentially independent problems. – Michael Hoff Aug 30 '20 at 14:13
  • backend and frontend code in the same repository is the source of your problems. it is impossible to have two repositories something like acme-web and acme-api ? Did you solve your problem? – JRichardsz Aug 31 '20 at 02:19
  • Merge the branches to your branch locally, solve any conflict and only then push: `git checkout my-branch; git merge branch-a` – Qumber Sep 04 '20 at 07:39
  • 1
    I think [this](https://stackoverflow.com/q/47835297/1290731) may be a duplicate. – jthill Sep 04 '20 at 22:15

2 Answers2

3

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.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Many thanks for your reply. Could you elaborate on your second approach? I don't see how you would avoid the problem with update-merges from develop onto the 'main' feature branch. – Michael Hoff Aug 29 '20 at 15:08
  • The second approach makes a feature branch a collection of individual developer feature branches, and each developer rebases their own changes onto the main development before reintegrating them into the main feature branch, meaning they solve their own conflicts during the rebase. – bk2204 Aug 29 '20 at 15:41
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
  1. 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
  1. 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.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Did not work for me; tried having a file for both frontend and backend with line change and a line addition. Also, the fix with this solution gets harder if another feature branch goes in when the intermediate branches (B and F) are being merged to the feature branch – npk Jul 26 '22 at 12:52
  • @npk: the OP specified that in his case, the teams explicitly worked on separate files, this answer gives a technical way to allow to resolve merge conflicts separately with this information.. As far as workflows go, I would advise you to follow bk2204's suggestions : merge early, involve people from both teams to solve merge conflicts spanning the two sides. – LeGEC Jul 26 '22 at 13:19
  • @npk : you will also note that the diagram suggests to first merge `master` into `feature` which prevents the "other features get merged in between" issue. – LeGEC Jul 26 '22 at 13:21