1

I have a master branch(#A) serving as the development branch for all developers and I have the other branch(#B) serving as the customer release branch.

Once release branch is created, sometimes we dev features on this branch. I'll periodically merge the release back to master branch.

The branches will look like below:

  C1 <- C2 <-- C3 <---- M1 <-- C5 <-- M2 <-- C6             (branch #A)
         ^               |             |
         |--D1 <- D2 <- D2 <-- D3 <-- D4 <-- D5             (branch #B)

When I do the first merge (M1), I will fix many conflicts.

The question is: When I do the second merge, is there any way to avoid fix those conflicts again?

Johnny
  • 21
  • 2

1 Answers1

1

I would look into git rerere that I mention in "Are there any downsides to enabling git rerere?".

If you have already done M1, you can activate rerere and train it, in order for git to record past conflict resolution.

As commented, said identical conflicts should not occur again, if your changes are different from those already merged.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I don't think this answer addresses the question correctly. `rerere` won't help in OP's situation. – j6t Sep 08 '21 at 07:13
  • @j6t Indeed. Let us wait for more details from the OP. – VonC Sep 08 '21 at 08:14
  • I just looked into the documentation of git rerere. It seems that is what I am looking for. I will try it. Thanks for providing the re-training script. – Johnny Sep 08 '21 at 08:31
  • @Johnny I'm not sure. `rerere` is most useful when you repeat the same merge, for example, when you rebase a topic branch again and again. But your chart shows a typical mergy history. That is not where `rerere` can help. – j6t Sep 08 '21 at 08:48