1955

How do I resolve a git merge conflict in favor of pulled changes?

I want to remove all conflicting changes from a working tree without having to go through all of the conflicts with git mergetool, while keeping all conflict-free changes. Preferably, I want to do this while pulling, not afterwards.

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
sanmai
  • 29,083
  • 12
  • 64
  • 76
  • 4
    possible duplicate of [git merge -s ours, what about "theirs"](http://stackoverflow.com/questions/173919/git-merge-s-ours-what-about-theirs) –  Apr 12 '14 at 02:41
  • 3
    Duplicate of [git pull from remote.. can I force it to overwrite rather than report conflicts?](http://stackoverflow.com/questions/4785107/git-pull-from-remote-can-i-force-it-to-overwrite-rather-than-report-conflicts) You can see the same solution there. – Dan Dascalescu Jul 15 '14 at 00:39
  • 4
    @DanDascalescu Accepted answer there doesn't answer this questions, so clearly it isn't a duplicate. Plus, that other question is quite ambiguous: it is very hard to tell what is asked. All in all I can't agree with you. What is you point in this? – sanmai Jul 15 '14 at 00:44
  • 3
    @sanmai You have two answers - and you accepted one of them. Can you better explain what you are expecting in an answer and how much more detail do you want here? – Edward Thomson Jul 25 '14 at 02:31
  • 3
    @EdwardThomson well, actually I was thinking to give this reputation for the first answer, but if you ask, I might wait and see if a better answer comes up – sanmai Jul 25 '14 at 02:42

19 Answers19

2139
git pull -s recursive -X theirs <remoterepo or other repo>

Or, simply, for the default repository:

git pull -X theirs

If you're already in conflicted state...

git checkout --theirs path/to/file
sanmai
  • 29,083
  • 12
  • 64
  • 76
Pascal Fares
  • 21,959
  • 2
  • 14
  • 12
  • 55
    Note that `-s recursive` here is redundant, since that's the default merge strategy. So you could simplify it to `git pull -X theirs`, which is basically equivalent to [`git pull --strategy-option theirs`](http://stackoverflow.com/a/10697551/456814). –  Jul 28 '14 at 03:26
  • 9
    If I do this, I end up back in the `MERGING` state. I can then `git merge --abort` and try again, but each time I end up with a merge occurring. … I know that a rebase was pushed to my upstream though, so perhaps that's causing this? – Benjohn Jul 14 '16 at 09:03
  • 49
    Be careful with `git checkout --theirs path/to/file`. Used it during rebase and got unexpected results. Found explanation in doc: _Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased._ – Vuk Djapic Jul 06 '17 at 15:13
  • 15
    Note that `git checkout --theirs/--ours path` man page states that it works for **unmerged paths**. So if there were no conflict in path, it is already merged this command will do nothing. This might case issues when you want for example 'theirs' version of a whole sub-folder. So in such case it would be safer to do `git checkout MERGE_HEAD path` or use commit hash. – fsw Aug 23 '17 at 09:17
  • 9
    `git pull -X theirs` creates a merge commit if there are conflicts (e.g. if another committer ran `git push -f` to the remote). If you don't want merge commits, run instead `git fetch && git reset --hard origin/master`. – Dan Dascalescu Jan 23 '18 at 10:02
  • 1
    One thing to note with this technique is that, if you're not happy with the result of the `checkout` command, you can run it again with the `--conflict=merge` option to get the full conflict markers in the file again. – Shinigami Mar 25 '18 at 01:32
  • 2
    `git checkout --theirs .` – Black Mar 25 '19 at 16:45
  • 7
    *NB*: `git checkout --theirs path/glob` doesn't resolve conflicts using ours/theirs. It takes the entire file from either `ours/theirs`. If there are changes that are not conflicts, they will be discarded. – CervEd Jul 23 '21 at 10:25
  • This approach failed with: "CONFLICT (rename/rename): Rename ..." and "CONFLICT (file location):..." – William Entriken Apr 21 '23 at 21:31
1355

You can use the recursive "theirs" strategy option:

git merge --strategy-option theirs

From the man:

ours
    This option forces conflicting hunks to be auto-resolved cleanly by 
    favoring our version. Changes from the other tree that do not 
    conflict with our side are reflected to the merge result.

    This should not be confused with the ours merge strategy, which does 
    not even look at what the other tree contains at all. It discards 
    everything the other tree did, declaring our history contains all that
    happened in it.

theirs
    This is opposite of ours.

Note: as the man page says, the "ours" merge strategy-option is very different from the "ours" merge strategy.

Giacomo1968
  • 25,759
  • 11
  • 71
  • 103
Ikke
  • 99,403
  • 23
  • 97
  • 120
  • 2
    Here is more detailed explanation: http://lostechies.com/joshuaflanagan/2010/01/29/how-to-resolve-a-binary-file-conflict-with-git/ – mPrinC Sep 17 '13 at 00:34
  • 255
    Also `git checkout --theirs` to operate on a single conflicting file – dvd Jul 31 '14 at 12:24
  • 59
    This doesn't work if you are already in the conflict resolution state. In that case I believe the best way to resolve is to `git checkout -- the/conflicted.file`; and then `git add` their changes. – ThorSummoner Sep 12 '14 at 17:58
  • 65
    @ThorSummoner In that case, there is git checkout --theirs path/of/file. That way, you don't have to manually look up the correct hash. – Ikke Sep 13 '14 at 19:26
  • 11
    @Ikke That should basically be its own answer (and the accepted answer at that) if you ask me. – ThorSummoner Sep 14 '14 at 02:16
  • 1
    "git merge local/master --strategy-option theirs" worked for me – Yasen May 13 '15 at 08:37
  • 1
    I get `error: Merging is not possible because you have unmerged files.` – ShadSterling Feb 07 '17 at 19:28
  • 1
    Could you update this answer for `Git 2.0+`? Because from 2.0 onwards `git merge` does no longer have `--strategy-option`. There is only `--strategy`, but this option does not have a `theirs` strategy. Choices are `octopus`, `ours`, `recursive` (default?!), `resolve`, `subtree`. – daniel451 May 30 '17 at 19:58
  • 1
    @daniel451 Why do you think that option has been removed? It's still available. See: https://git-scm.com/docs/git-merge#git-merge--Xltoptiongt – Ikke Jun 01 '17 at 04:39
  • 1
    Nevermind, I just noticed that my zsh-setup apparently lacks auto-completion support for `--strategy-option` and I have overlooked this option.. – daniel451 Jun 01 '17 at 06:19
  • 1
    @dvd that's exactly the option I was looking for. I want to initiate the merge as usual, but when resolving the conflicts, I want to be able to resolve individual files with the appropriate strategy. Thank you! – asgs May 07 '18 at 08:24
  • 1
    I did with git merge OTHER_BRANCH_NAME --strategy-option theirs – V-SHY Dec 04 '18 at 15:45
  • 1
    If you're already in the conflict resolution state, you can cancel the merge by first doing `git merge --abort`, and then using `git merge --strategy-option theirs`. – commscheck Sep 02 '19 at 23:55
  • 2
    `git merge --strategy-option theirs BRANCH_THEIRS` still generated conflicts to me ... – mljrg Oct 13 '20 at 13:53
  • 1
    Exactly what I was looking for. Merge it properly where you can and accept theirs (ours) where can't. Saved me tons of time resolving conflicts manually. – Dmitriy Jul 11 '22 at 06:59
  • lol, it's classic git to have two very similar-sounding commands that do very different things. it'd be so easy to absent-mindedly confuse "strategy" and "option"! – tobybot Mar 01 '23 at 22:14
  • Merging a branch that reintroduces a file that was deleted in the target branch with `--ours` still ends in conflict. – Ledorub Apr 09 '23 at 14:54
758

If you're already in conflicted state, and you want to just accept all of theirs:

git checkout --theirs .
git add .

If you want to do the opposite:

git checkout --ours .
git add .

This is pretty drastic, so make sure you really want to wipe everything out like this before doing it.

lots-to-learn
  • 7,807
  • 1
  • 9
  • 11
  • 79
    or, don't use the `.` and specify the file(s) in place of the dot that you want to checkout. less "drastic" & exactly what you want to do, presumably. – manroe Dec 16 '15 at 00:56
  • Have I missed something, or don't you have to `git reset` the conflicted files **before** `git checkout`? – Vitor Feb 25 '16 at 19:38
  • 18
    this doesn't work if the file has been removed from the other branch: '' does not have their version – Japster24 Mar 02 '16 at 16:52
  • 4
    Would upvote more if I could, keep coming back to this answer every now and then. – tarikki Sep 14 '16 at 04:04
  • 9
    Use `git add -u` instead to skip files that are not under version control. – Sudipta Basak Oct 27 '16 at 20:56
  • 8
    Hypothetical case, three changes in a file, one conflicting, two without conflict, would this solution apply non conflicting changes and resolve the conflicting change to ours? Or would it take only ours version ignoring non conflicting changes from theirs? – pedromarce Feb 28 '17 at 14:50
  • @Japster @SudiptaBasak So [that `-u` was magic](https://stackoverflow.com/questions/2190409/whats-the-difference-between-git-add-and-git-add-u). Thanks! – ruffin May 26 '17 at 22:35
  • 1
    If its Monday morning and you haven't yet had coffee. Running the command above doesn't move the files from a "both modified" state. – DickieBoy Oct 16 '17 at 09:18
  • 2
    It's worth mentioning that like most git actions you can apply this to paths, e.g. `git checkout --theirs wp-content/languages/` which will grab just files under that path from the incoming branch, and leave the rest untouched. – Rob Murphy May 29 '18 at 10:31
  • 9
    @pedromarce `git checkout --ours ` takes **all** ours changes including non conflicting. Be careful with that. – Robert Jakubowski Nov 13 '19 at 07:51
  • 3
    Does `--theirs` mean `Incoming change`? While `--ours` mean `Current change`? – tonix May 12 '20 at 14:00
  • 3
    @tonix, always interpret git terminology from the perspective of a paranoid Linus Torvalds protecting linux from outside changes. If you apply that mindset, then yes "theirs" means the change being merged in (or merge candidate) and "ours" means the side that will receive the merge (the branch that will be updated). Notice, all of this is strictly based on the orientation of the git merge command (not your larger purpose or a local / origin setup, etc). I hate the "ours/theirs" terminology because it has a technical meaning in the `git merge` which can be opposite of how it sounds. – combinatorist Aug 19 '20 at 15:43
  • 4
    `ours` and `theirs` refers to `HEAD` and whatever is being merged into `HEAD`, ie the current commit checked out. Think of `ours` as *current* and `theirs` as *incoming*, not as in what's your work vs. others. What is ours/theirs will depend on if you're resolving a conflict from stash/rebase/merge. *NB* that `git checkout --ours/--theirs` just picks one version and **completely discards** the other. Ie. this answer is probably not what you want. See my answer for how to only discard conflicting changes – CervEd Feb 02 '22 at 12:17
245

OK so, picture the scenario I was just in:

You attempt a merge, or maybe a cherry-pick, and you're stopped with

$ git cherry-pick 1023e24
error: could not apply 1023e24... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Now, you view the conflicted file and you really don't want to keep your changes. In my case above, the file was conflicted on just a newline my IDE had auto-added. To undo your changes and accept their's, the easiest way is:

git checkout --theirs path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

The converse of this (to overwrite the incoming version with your version) is

git checkout --ours path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

Surprisingly, I couldn't find this answer very easily on the Net.

Theodore R. Smith
  • 21,848
  • 12
  • 65
  • 91
  • 20
    Note that, if one performs a `git status` between `checkout` and `add`, the file still shows as "both modified". – bishop Mar 25 '16 at 12:56
  • 2
    Do you know if there is a way to do this for all files that are in a conflicted state? If so it'd be a nice extension to your answer. – Drew Noakes Mar 06 '18 at 08:42
  • 3
    I do this: `git reset --hard` and then `git pull [remote server name] [branch name] -Xtheirs` (undoes the merge then pulls the new stuff on top of my stuff) - not sure if this what you want. – ssaltman May 22 '18 at 19:17
68

If you're already in conflicted state, and do not want to checkout path one by one. You may try

git merge --abort
git pull -X theirs
Lee Chee Kiam
  • 11,450
  • 10
  • 65
  • 87
63

The git pull -X theirs answers may create an ugly merge commit, or issue an

error: Your local changes to the following files would be overwritten by merge:

If you want to simply ignore any local modifications to files from the repo, for example on a client that should always be a mirror of an origin, run this (replace master with the branch you want):

git fetch && git reset --hard origin/master

How does it work? git fetch does git pull but without merge. Then git reset --hard makes your working tree match the last commit. All of your local changes to files in the repo will be discarded, but new local files will be left alone.

Dan Dascalescu
  • 143,271
  • 52
  • 317
  • 404
  • 4
    +1 - `git fetch && git reset --hard {remote}/{branch}` was what solved my problem. I needed to completely ditch my own changes in favour of "theirs" state of a branch, but the `git pull -X theirs` choked on some moved/renamed files. Thanks! – Ivaylo Slavov Feb 05 '18 at 18:28
  • 1
    but if I do `git pull` afterwards I go back to conflicting state, may be I shouldn't have git pulled, but why not? – Vivek Shukla Aug 28 '20 at 12:45
26

Please not that sometimes this will not work:

git checkout --ours path/to/file

or

git checkout --theirs path/to/file

I did this instead, assuming HEAD is ours and MERGE_HEAD is theirs

git checkout HEAD -- path/to/file

or:

git checkout MERGE_HEAD -- path/to/file

After we do this and we are good:

git add .

If you want to understand more, see wonderful post of torek here : git checkout --ours does not remove files from unmerged files list

Community
  • 1
  • 1
Nicolas D
  • 1,182
  • 18
  • 40
25

VS Code (integrated Git) IDE Users:

If you want to accept all the incoming changes in the conflict file then do the following steps.

1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming

Similarly you can do for other options like Accept All Both, Accept All Current etc.,

SridharKritha
  • 8,481
  • 2
  • 52
  • 43
24

To resolve all conflicts with the version in a particular branch:

git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

So, if you are already in the merging state, and you want to keep the master version of the conflicting files:

git diff --name-only --diff-filter=U | xargs git checkout master
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
Ariel Alvarez
  • 451
  • 5
  • 11
  • 1
    And for people on windows without access to pipe xargs, how does this translate? – tsemer Dec 09 '16 at 16:18
  • 1
    Wouldn't it skip your changes completely? Even those which are not in conflict state? – Valentin H Jan 15 '18 at 12:24
  • 1
    This is what I ended up doing. Unfortunately it subsequently requires either a `git cherry-pick --continue` *or* a `git commit --allow-empty` command to commit these changes, and there seems to be no system behind which command is required, which makes automating this a pain. I’m currently solving this by testing for the existence of a `.git/COMMIT_EDITMSG` file but that seems hacky and brittle, and I’m not yet convinced that it always works. – Konrad Rudolph May 07 '19 at 16:41
  • 2
    This is good, means if you manually resolve some (and do `git add`) then you can bulk resolve the rest via this. `git checkout --ours` / `git checkout --theirs` is useful too. – rcoup Mar 25 '20 at 15:21
19

git checkout --ours/theirs doesn't exclusively resolve conflicts. It checks out (takes the entire file) from either ours/theirs.

Suppose we have a file foo with changes in two commits/branches/trees/whatever. If there was a conflict introduced by theirs, as well as a modification, and we want to resolve the conflict using ours -- then using checkout --ours foo will discard the changes introducing conflicts, but also the modifications.

Using SED

Resolve using theirs:

sed -i -e '/^<<<<<<</,/^=======/d' -e '/^>>>>>>>/d' foo

  • -i Modify the file in place,
  • /^<<<<<<</,/^=======/d delete everything between and including <<<<<<< and ======= (ours)
  • /^>>>>>>>/d delete the remaining conflict marker
  • -e specify multiple patterns to SED
  • foo the file

Resolve using ours:

sed -i -e '/^<<<<<<</d' -e '/^=======/,/^>>>>>>>/d' foo

I made a script that you can call git resolve -o/-t/-b.

Creating a custom merge tool

You can create custom merge tools. Building on the above sed scripts you can put something like this in your git-config:

[mergetool "ours"]
    cmd = "sed -i -e '/^<<<<<<</d' -e '/^=======/,/^>>>>>>>/d' -- $MERGED"

and call it git mergetool --tool=ours

Merge styles

Note that there are other non-standard merge styles, like diff3 and zdiff3 as pointed out by @Stavros in the comments. The number of conflict markers is also not hard coded to 7 in git. I believe it's mainly just a default and as I recall, it can be configured.

The basic sed script can be tweaked to work with all configurations.

CervEd
  • 3,306
  • 28
  • 25
  • 3
    I started discussion about it on a Git mailing list it for a possible solution: https://public-inbox.org/git/3e1548ab-5e20-9555-bd10-d6cbf2ffbce4@gmail.com/ – bam Dec 28 '21 at 23:23
  • 1
    This problem with the whole file being checked out instead of just resolving the actual merge conflicts is why I found all other answers not helpful and even wrong based on the question wording. It's surprising and unfortunate thought that there is no integrated tool for this in git and sed has to be used instead. – mxmlnkn Apr 01 '22 at 11:43
  • 2
    This answer highlights a criticial and subtle point on what `git merge --theirs|--ours` do, i.e pick the whole file from theirs or ours branch. Currently there is no built-in command line option in git to resolve _ONLY_ the conflict part, picking theirs or ours. This can only be done by manual editing. Some merge tools (e.g Tortoise, P4, kdf3 etc) help. The `sed` option in this answer is handy and the one closest to a command line option. – FractalSpace Nov 14 '22 at 18:38
  • 1
    @FractalSpace you can use the linked script (I've updated it), put it in your path to run `git resolve -t/--theirs -o/--ours -b/--both -a/--add`. Bug reports and PRs are welcomed and appreciated – CervEd Nov 14 '22 at 19:42
  • 1
    @CervEd I am using your linked script and it is working fine so far (thanks). Also the version I am using does not have `-a`, but it adds the files after resolving conflict (which is good). – FractalSpace Nov 14 '22 at 20:59
  • 1
    @CervEd as for feedback, an option to be able to pick 'hunks' for either side would be nice. Also, instead of 'both', I prefer something like 'thersthenours' and 'oursthentheirs', matching what most gui tools offer. – FractalSpace Nov 14 '22 at 21:14
  • 1
    @FractalSpace Awesome! The `-a` flag was added to specifically add. Sometimes I don't want to add but rather do different things with the resolved files. What's the difference of 'theirsthenours' and 'oursthentheirs'? `--both`, treats both as valid, and will "accept" both sides. I've thought about hunks but I personally prefer `vimdiff` in most such cases. The script is mainly designed to be how I would expect `checkout --ours/--theirs` to work and quickly but roughly resolve conflicts in favor to either side. Personally, I use hunks after such a resolution to do anything more granular – CervEd Nov 14 '22 at 21:32
  • 1
    @bam Looks like your git thread is dead – FractalSpace Nov 15 '22 at 12:54
  • 1
    For `merge.conflictStyle == ?diff3`, `ours` `sed` becomes: `sed -i -e '/^<<<<<<>>>>>>/d' -- $MERGED` – Stavros Feb 10 '23 at 07:18
  • 1
    @Stavros I didn't know about conflict styles, thanks! It shouldn't be hard to match either default, diff3 or zdiff3 – CervEd Feb 10 '23 at 09:57
15

Update 2023!

If you want to accept all current changes and ignore any incoming changes, you could accomplish this:

git merge [branch] --strategy-option ours

[branch] should be replaced with the name of the branch you are merging into your current branch.

If, instead, you know you want to overwrite any current changes and accept all conflicts from incoming changes, you can use the theirs strategy instead:

git merge [branch] --strategy-option theirs
S. Hesam
  • 5,266
  • 3
  • 37
  • 59
5

from https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging

This will basically do a fake merge. It will record a new merge commit with both branches as parents, but it will not even look at the branch you’re merging in. It will simply record as the result of the merge the exact code in your current branch.

$ git merge -s ours mundo

Merge made by the 'ours' strategy.

$ git diff HEAD HEAD~

You can see that there is no difference between the branch we were on and the result of the merge.

This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on. For example, say you branched off a release branch and have done some work on it that you will want to merge back into your master branch at some point. In the meantime some bugfix on master needs to be backported into your release branch. You can merge the bugfix branch into the release branch and also merge -s ours the same branch into your master branch (even though the fix is already there) so when you later merge the release branch again, there are no conflicts from the bugfix.

A situation I've found to be useful if I want master to reflect the changes of a new topic branch. I've noticed that -Xtheirs doesn't merge without conflicts in some circumstances... e.g.

$ git merge -Xtheirs topicFoo 

CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.

In this case the solution I found was

$ git checkout topicFoo

from topicFoo, first merge in master using the -s ours strategy, this will create the fake commit that is just the state of topicFoo. $ git merge -s ours master

check the created merge commit

$ git log

now checkout the master branch

$ git checkout master

merge the topic branch back but this time use the -Xtheirs recursive strategy, this will now present you with a master branch with the state of topicFoo.

$ git merge -X theirs topicFoo
Amos Folarin
  • 2,059
  • 20
  • 18
4

I had a long-running next-version branch with tons of deletions to files that had changed on develop, files that had been added in different places on both branches, etc.

I wanted to take the entire contents of the next-version branch into develop, all in one whopping merge commit.

The combination of the above commands that worked for me was:

git merge -X theirs next-version
# lots of files left that were modified on develop but deleted on next-version
git checkout next-version .
# files removed, now add the deletions to the commit
git add .
# still have files that were added on develop; in my case they are all in web/
git rm -r web

Not a new answer, just combining bits from many answers, partly to reassure that you might need all of these answers.

Gordon
  • 19,811
  • 4
  • 36
  • 74
4

Accept remote changes (theirs) and in case there are conflicts you get the following error:

fatal: Not possible to fast-forward, aborting.

so you may want to pull and accept their changes with fast-forward:

$ git pull -X theirs --ff
Shayan Amani
  • 5,787
  • 1
  • 39
  • 40
2

In Emacs using smerge-mode, to resolve all conflict markers using either mine or theirs, we can define:

(defun aj/smerge-keep-mine-all ()
  ""
  (interactive)
  (save-excursion
    (beginning-of-buffer)
    (while (ignore-errors 'user-error (progn (smerge-next) t))
      (smerge-keep-mine))))

(defun aj/smerge-keep-other-all ()
  ""
  (interactive)
  (save-excursion
    (beginning-of-buffer)
    (while (ignore-errors 'user-error (progn (smerge-next) t))
      (smerge-keep-other))))
arvidj
  • 775
  • 5
  • 25
2

Even though there are already great answers here, I wanted to post this answer to document how to resolve all merge conflicts in Visual Studio (in favor of our changes as an example).

If instead, you want to accept incoming changes (their changes) as asked in this question, just replace ours in Step 6 below with theirs. It's as simple as that.


Summary of what I'm doing here:

Merge dev into my branch and while doing that if there are any merge conflicts, take changes from my branch.

(After this is done, I'll create a PR to finally push the changes from my branch to dev).


Step 1

Checkout the branch where you want to merge dev into by going to 'Manage Branches' and double clicking your branch name. In my case, it's feature\InterimBranchToDev2-AshK.

Step 2:

Right click dev and click Merge 'dev' into 'feature/InterimBranchToDev2-AshK'

Step 3:

You'll see a ton of merge conflicts!

Now it's very tedious to right click each of those files and click Keep Current (feature/InterimBranchToDev2-AshK), so let's Abort this and take care of this using command line.

Step 4:

Hit Abort

Step 5:

Open cmd

Step 6:

Type git merge --strategy-option ours --no-commit dev and hit enter

What this basically means: "Merge dev into current branch and if there are any merge conflicts, take version from current branch, and also don't commit the merge yet".

This will be the output: Automatic merge went well; stopped before committing as requested

Step 7:

Now go to Visual Studio, conflicts are nicely taken care of and you can enter your message and commit:

Ash K
  • 1,802
  • 17
  • 44
2

I found that I needed to specify origin main as the branch I was merging into.

git merge **origin main** --strategy-option theirs
James Prentice
  • 134
  • 1
  • 6
2

Starting with an example, We have a main branch and a dev branch having some conflicts

Pull updates before checkout, so the main branch is up to date:

git checkout main
git pull
git checkout dev

Then merge:

  • if you want to accept incoming changes from the main to be the source of truth:
git merge --strategy-option theirs main
  • if you want to accept the current changes in dev as the source of truth:
git merge --strategy-option ours main

ours and theirs here are special words, they have meaning and are not custom, but main or dev could be any other two branches you want to merge together.

Arsham Arya
  • 1,461
  • 3
  • 17
  • 25
  • There will be merge commit right? But what if we don't want to merge the branches, but want to cherry-pick the conflicting commit instead? – bam Jul 04 '23 at 11:30
1

It's Solved. To resolve all conflicts with below simple steps.

git fetch && git reset --hard origin/master

git pull -X theirs

git pull origin master
Thirsty Six
  • 399
  • 1
  • 6
  • 13