Git How to merge a branch into a leading branch by completely rewriting the leading branch

Question

I started working with the master branch. Almost a year ago, I created another dev branch in which I made some changes. From then on, I continued to work on the dev unit. Now I want to combine dev into a wizard, which leads to a lot of conflicts. I want to merge dev into master, rewriting the contents of the main branch, that is, for any conflict that occurs, I want to keep the version of the dev branch. How can I do that?

Answer 1

You want to use the "merge with your own" strategy, which is set using the -X flag

git checkout master git merge -X theirs dev 

Answer 2

You can specify a strategy option using the -X switch:

 git checkout master git merge -X theirs dev 

A little explanation. -X theirs means: use a recursive strategy with concatenation, but discard their changes if the strategy cannot resolve the conflict.

This is different from -s ours (for some reason there is no -s theirs ), which would be greedy for our solution to always be resolved.

git-merge(1) The strategy merging section provides a deeper explanation for this.

Answer 3

You can force click on the master with all your commits

 git push -f origin master 

Answer 4

As Paulo Bu noted , git provides different methods for this when you want to merge with “ours,” but only one “out of the box” “when you want to merge with“ ours. ”These two examples should be illustrated:

 $ git merge -s ours deadbranch # merge deadbranch and ignore all its code 

or

 $ git merge -X ours livebranch # merge livebranch but use ours when conflicting 

Let me also note that when you use git merge , git first finds the "merge base", the point at which the two branches were in sync:

  o - X <-- master / o - o - B \ o - Y <-- otherbranch 

Here, B represents the commit, which is the base of the merge, X is the end of your branch ( master ), and Y is the end of another branch. What git will do is diff B vs X and B vs Y

Let's say that in “our” master branch we have unchanged , no-conflicts , conflict and removed files. These names refer to what happened in the other two branches.

The unchanged file does not change in the branch to be merged (that is, diff from B to Y shows nothing for the unchanged file). git merge never affects it, so nothing changes no matter what arguments we give git merge .

Other files have some changes in master and / or in another branch.

The no-conflicts file has one change in master at the top and one change in another branch at the bottom. These two changes do not conflict. git merge -s recursive changes, regardless of whether you use the -X ours option. However, git merge -s ours will undo their change, saving our version of the no-conflicts file. In this case, the result is different.

The conflict file has one change in the main file at the top of the file and another change in another branch also at the top. (Changes can be anywhere, they just have to intersect. At the top, this overlaps.) This means that these changes conflict. Using git merge -s recursive , you will receive a complaint and must resolve the conflict. Add -X ours and git will accept your changes, discarding their changes. Using git merge -s ours , git will accept your change and throw away their change, so for this case the result will be the same.

The removed file has no changes in master , but is deleted in another branch. In this case, git merge -s recursive will delete the file, regardless of whether you use -X ours . However, git merge -s ours will ignore the deletion.

In short, the difference between -s ours and -s recursive -X ours is that with the first, git completely ignores diff from B to Y ; with the latter, git tries to combine the differences B -to- X (ours) and B -to- Y (them), but in case of a conflict during the merge, it chooses the change B -to- X .

With -X theirs (which really is -s recursive -X theirs ), git tries to combine the differences, and in case of conflict, chooses to change B Y to B - to- X .

---

Reach the equivalent of -s theirs , although git does not have a built-in built-in device. To do this, use git merge --no-commit otherbranch , then git rm -rf . from the top level to remove the resulting merge (with or without conflicts), then git checkout otherbranch -- . from the top level to otherbranch tree and index based on otherbranch . Then just git commit result. However, this is rarely needed, so git has no built-in strategy.