29

I just want to know, if there is any way, to resolve merge commits, of two git branches, without actually merging them.

Assuming, I have a branch "featureMy"; my colleague created another branch "featureHis". Both branches are created on "master" branch.

My colleague then created a merge request for his branch "featureHis" into master. When I then create my merge request of "featureMy" into master, I want to ensure, that it will not conflicts with master after "featureHis" is merged.

Usually, I will merge "featureHis" into "featureMy" before. However, this is not that satisfying, because I have a additional merge commit as "noise" and my merge request will contain changes from "featureHis".

Is there a way, so that I can solve the merge conflicts, without creating a merge commit?

Kind regards

Timo
  • 357
  • 1
  • 3
  • 7
  • 2
    You could do `--no-commit` if you want to see if there will be a conflict. http://stackoverflow.com/a/501461/3000179 – ʰᵈˑ Jul 27 '16 at 15:12

2 Answers2

15

One standard way to avoid having merge commits is to use rebasing in place of merging. Consider the following scenario:

master:     A
featureMy:  A -- B
featureHis: A -- C

Assuming that only these two branches are extant from master, then one of you will merge with master first. Let's say it is your colleague who gets there first. Then the diagram would look like this:

master:     A -- C
featureMy:  A -- B
featureHis: A -- C

Your colleague's commit is now in the master branch. Now if you use a merge-based workflow, you would first merge master into your branch, and then you merge your branch back into master. This would result in:

master:     A -- C -- E
featureMy:  A -- B -- D
featureHis: A -- C

Now both your branch and the master branch have ugly merge commits in them. However, if you had rebased your branch on master, you would be left with:

master:     A -- C
featureMy:  A -- C -- B'    (B' indicates that this a new commit, not B)
featureHis: A -- C

Now your branch featureMy is actually ahead of the master branch. You can simply push your commit in, directly on top of master, with no conflicts. This results in the following diagram:

master:     A -- C -- B'
featureMy:  A -- C -- B'
featureHis: A -- C

Notice that there are no merge commits anywhere. In fact, both your featureMy branch and master have identical linear histories.

Long live git rebase.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • I would add that in order to follow his current workflow, he should first rebase branch `featureMy` onto `featureHis` and resolve any conflicts. After branch `featureHis` is merged into `master`, he can rebase `featureMy` onto `master` and merge to `master`. – geoji Jul 27 '16 at 21:36
  • 2
    Unfortunately, very rarely it is a real-life scenario. Most of the time `featureHis` and `featureMy` are remote branches, thus re-base will be disastrous and will not work. – Alex D Aug 07 '19 at 16:37
  • What if all I want is `A -- B'` without the `C` in `featureHis`?? – Loi Nguyen Huynh Sep 06 '21 at 07:37
  • 1
    "if you don't want to use a rusty hammer to bang in a nail, you can always punch it with your fist" – Isaac Mar 28 '22 at 22:23
  • @Isaac It's a great and detailed answer. But nice attempt at spreading FUD about rebase. Many teams work exactly like this answer describes and have a clean and sequential git history without noisy merge commits as a result. – timotgl Jul 13 '23 at 10:45
9

If your merge conflicts can be solved by using one version of a file entirely, here's a solution.

Say you want to merge into a branch called qa and there are conflicts in composer.json and composer.lock. qa contains later versions that you want to use instead of what's in your branch.

git checkout origin/qa -- composer.json composer.lock
git commit -m "fixed merge conflicts without merging"
amacrobert
  • 2,707
  • 2
  • 28
  • 37