1

I have been using git for a while, but my merging has always been fairly simple. Create a branch, merge it to master. Sometime 2 people have branches out that touch the same code, so there is a merge conflict, typically easy to fix.

But now I have a case where a branch was made and lots of major changes were done. At the same time lots of changes were made to master, and the same files were changed in both. We want all the changes to both branches merged. We fully expect there to be conflicts, but we want to keep them to a minimum.

My question is, is there any difference between merging master to the branch, resolving the conflicts, then merging that to master with merging the branch to master and resolving the conflicts there?

Are there any hints or best practices for doing a complex merge like this to avoid losing any changes?

NormanRobins
  • 11
  • 1
  • 1
    Not really.... to git it's the same thing. If you merge either way, conflicts will be the same, the difference is that in the conflict blocks, the order of the 2 sections from the 2 branches are inverted (notice I didn't say anything about the common ancestor.... that's on purpose, if you are using diff3 as merge conflict style... that part will remain in the middle if you are using it). You should remain in the base branch and merge the feature branch just so that when you do something like `git checkout main~2` it doesn't go into the feature branch but follows the main branch revisions. – eftshift0 Feb 18 '21 at 22:22
  • 1
    Have a look at [`git imerge`](https://github.com/mhagger/git-imerge) for the slow-and-careful way to do this. Your two alternatives will show the same conflicts with different "ours" and "theirs" labels. – jthill Feb 18 '21 at 22:22
  • Thanks - imerge looks very useful. – NormanRobins Feb 18 '21 at 22:33

1 Answers1

1

You should not merge master to a topic branch.
A best practice is for specific branches (like a topic/feature branch) to be merged to integration branches (like "development" or "master")

In your case, a git rebase is better, to resolve locally any conflict between your branch and master.
Then, the merge from your branch to master will be trivial, because all commits will have been recreated on top of master:

cd /path/to/local/repo
git fetch
git switch myBranch
git rebase origin/master
# resolve conflict
git push --force

git switch -C master origin/master
git merge myBranch
git push
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • What it the difference between a merge and a rebase? – NormanRobins Mar 01 '21 at 01:10
  • @NormanRobins See https://medium.datadriveninvestor.com/git-rebase-vs-merge-cc5199edd77c?gi=bc2161b770f2: the goal is to *replay* `myBranch` commits on top of the updated `origin/master`, before pushing. – VonC Mar 01 '21 at 06:22
  • We ended up rebasing and it's been a bit of a nightmare. We had branch A.2 and we rebased master into that, then merged the rebased A.2 into master and pushed it. We did not push the rebased A.2 as we wanted that to not have master's changes. Development then continued on A.2 and master and a few days later we rebased again. That found conflicts we fixed in the first rebase, and a slew of new conflicts in files that had not change in either branch between the 2 rebases. This was all very unexpected. Did we do something wrong by rebasing twice? – NormanRobins Mar 11 '21 at 01:04
  • @NormanRobins Rebase master into that? You only rebase branches on top of master, never the reverse. That way, your branch is done on top of master changes. – VonC Mar 11 '21 at 05:49
  • we did this: git checkout A.2. git rebase master. git checkout master. git merge A.2. git push – NormanRobins Mar 11 '21 at 17:12
  • @NormanRobins That is correct. "We did not push the rebased A.2 as we wanted that to not have master's changes": you should push A2. It will include new A.2 commits on top of master. – VonC Mar 11 '21 at 17:16
  • A.2 is a product release version. They do not want what is in master part of that. But they want A.2 in master as base for their next release. My question is why, when I did the second rebase did I get conflicts I fixed during the first rebase as well as conflicts on files not changed in either branch since the first rebase. – NormanRobins Mar 11 '21 at 17:49
  • @NormanRobins You could check out `git rerere` (https://stackoverflow.com/a/5519698/6309, https://stackoverflow.com/a/3284288/6309, https://stackoverflow.com/a/61265041/6309) to allow some redundant conflicts to be automatically resolved for you. – VonC Mar 11 '21 at 19:47
  • Yes I was just reading about that. But it looks like it would have had to be enabled before we did the rebase, right? – NormanRobins Mar 11 '21 at 20:03
  • @NormanRobins No, you can retrain it: https://stackoverflow.com/a/12086598/6309, https://stackoverflow.com/a/45664714/6309 – VonC Mar 11 '21 at 20:05