git: Solve merge conflicts without performing a merge

Question

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

Answer 1

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.

Answer 2

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"