How to select a file from one branch when resolving a conflict during git rebase?

Question

Given a git repo with two branches, master and feature . When rebooting a function branch on top of the wizard using rebase master allows you to say that the a.txt file contains a conflict that must be resolved before the reboot continues.

I know that I can resolve the conflict in three stages:

• open a.txt in my editor to manually resolve the conflict
• calling git add a.txt to tell git I manually resolved the conflict
• call git rebase --continue move the redirect forward

Is there a way to avoid step 1 by telling git that I want the version of the file to be in the main branch, or I want the version of the file from the function branch not to perform steps 1 and 2 above.

Answer 1

Yes. In fact, there is not one way to do this.

The rebase and merge commands (and usually cherry picks) accept the same strategy and -X flags to go to the basic git merge mechanism. For the recursive -Xours and -Xtheirs select one or the other “sides” of the files in the case of a file modified in both branches that merge.

Or - this is completely different - in cases where the merger stops with a conflict, you can use git checkout with the --ours or --theirs flags to select a version from either side. (You can do this with other commands, here I will stick with --ours and --theirs , since they match the arguments of commands using merge mechanisms.)

This, of course, is different, because you can switch the selection:

 $ git checkout main Switched to branch 'main' $ git merge branch ... conflicts in files A and B ... $ git checkout --ours -- A # takes main:A $ git checkout --theirs -- B # takes branch:B 

Please note that this is very different from “our strategy” (the above strategy is “ recursive with ours option”). With “our strategy,” something completely different is happening. Start without it, re-merge again:

 $ git checkout main && git merge branch ... conflicts ... $ git checkout --ours -- AB # take main:A and main:B 

Say there is a third C file that git can merge on its own. When you do the above, git combines C , and you take main:A and main:B If you used git merge --strategy=ours branch , then git would take main:A , main:B and main:C It would branch:C changes, rather than automatically merging them.

I used git merge above because it makes “our” and “my” stuff “right”. I don't like git names, however, because when you rebase, our / their version becomes a replacement, because rebase works by going to the "other" branch and making a series of cherry picks. I.e:

 $ git checkout mine; git rebase theirs 

works under the influence of a (very) gross equivalent:

 $ git checkout theirs; git cherry-pick theirs..mine 

and then after that we shuffle the branch marks around so that theirs branch does not actually move. (This is not so bad inside :-), but he really does --ours means "them" and --theirs means "ours", which is pretty bad from the outside.)

Answer 2

You can use:

 git checkout --ours -- path/to/file 

Or:

 git checkout --theirs -- path/to/file 

... during a merge or search to select a specific version of a conflicting file; because rebasing is a little strange , --theirs in this case will be a feature version, --ours will be master .

Answer 3

I believe that what you are looking for that will get rid of all three steps,

git rebase master -X theirs

which will automatically resolve conflicts in favor of feature (current verified branch) or

git rebase master -X ours

The feeling of ours and theirs incompatible as arguments for rebase, as indicated in the description of the http://git-scm.com/docs/git-rebase option