4

I have a master branch on github, and a feature branch that has diverged quite a bit over time. Merging should not be impossible, but too much of a mouthful to do it in one go via git merge branch on one laptop, especially because different people will be better fixing conflicts in some files.

So we need a workflow to publicly, iteratively change branch into something where eventually git merge will be painless, because all conflict resolution has already been done stepwise. Ideas ? We can't be the first to have that issue, links to articles anyone ?

Thanks in advance, yours, Steffen

sneumann
  • 91
  • 1
  • Was merging master into your feature branch not feasible as you were working on it? Then you would have merge conflicts along the way, but smaller. – Lasse V. Karlsen Dec 23 '19 at 10:47

2 Answers2

1

You can create a new branch 'bmerge', from master, dedicated to that merge.

You can start merging feature to bmerge, and, instead of resolving all conflicts, commit the files with their merge conflicts and push!

Then you can ask your colleagues to fetch that bmerge branch, look for any merge conflict marker, and, depending on their familiarity with the code for that specific part, solve the conflict.

Once there is no more merge conflict, you can cherry-pick your colleagues resolution commits on top of feature, and merge to master.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Having tried this once, resolving merge conflicts without the help of the merge tools proved to be much harder than the alternative, which was to create a new branch from original branch point, then take some select commits from master and the feature branch and merge into this new branch, one pair at a time. We sort of replayed the "time" portion by pretending we had merged along the way. The merge conflicts still occurred, but they were smaller and easier to cope with. – Lasse V. Karlsen Dec 23 '19 at 10:49
  • @LasseV.Karlsen As long as (as in https://stackoverflow.com/a/18131595/6309) `merge.conflictstyle` is set to `diff3`, any VSCode would still show you an assistance on merge when opening a file with merge conflict marker. – VonC Dec 23 '19 at 10:51
  • We didn't use VSCode, we used Visual Studio, this was before VSCode time. – Lasse V. Karlsen Dec 23 '19 at 10:51
  • @LasseV.Karlsen OK, makes sense. – VonC Dec 23 '19 at 10:52
1

A method I have used in the past was to sort of replay the time-axis and pretending we had merged along the way.

Basically, we had this:

           *---*---*---*---*---*---*---*---*---*---*---*---*---*---* <-- master
          /
         /
*---*---A
         \
          \
           *---*---*---*---*---*---*---*---*---*---*---*---*---*---* <-- feature

We first created a new branch from the original branch point (A above), then we picked select commits from master and the feature branch and merged into the new branch, one pair at a time.

This still gave us merge conflicts, but they were smaller and easier to cope with.

The result was something like this:

           *---*---*---*---*---*---*---*---*---*---*---*---*---*---*-----M <-- master
          /         \                   \                   \           /
         /           \                   \                   \         /
*---*---A-------------M-------------------M-------------------M-------M <-- (temp)
         \           /                   /                   /       /
          \         /                   /                   /       /
           *---*---*---*---*---*---*---*---*---*---*---*---*---*---* <-- (feature)

All the M's above were the merges that in some way had a merge conflict, big or small.

I do think we had several more of them though like 7-8 merges in total, but we were able to pick some good commits from both master and feature by using the history and picking some stable points after refactoring and additions of new features, and then merge those together.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • Consider also [`git imerge`](https://github.com/mhagger/git-imerge), which is an automated way to do the above. – torek Dec 23 '19 at 16:44
  • Oh, nice, wasn't aware of that, that seems useful, I'll definitely make a note of that for future reference. Hopefully I will never get into this position again (yeah right). – Lasse V. Karlsen Dec 23 '19 at 22:15