333

I'm trying to pull code from my GitHub repo onto my server, but the pull keeps failing because of merge conflicts. I don't want to keep any of the changes that may have occurred on my local server since the last pull.

So is there a way I can force Git to overwrite with whatever version is in GitHub, rather than bother me about conflicts?

David Tuite
  • 22,258
  • 25
  • 106
  • 176
  • duplicate? http://stackoverflow.com/questions/4779715/error-when-running-git-pull-origin-master/4779723#4779723 –  Jan 24 '11 at 17:44
  • 4
    @nvm: Nope. This is about real merge conflicts, not untracked files that'd be overwritten. – Cascabel Jan 24 '11 at 21:32
  • @user173973 if this is a duplicate, then other way round. I think its unrelated. But good you answered the other question ;) – digitaldonkey Feb 17 '21 at 16:13

2 Answers2

556

If you truly want to discard the commits you've made locally, i.e. never have them in the history again, you're not asking how to pull - pull means merge, and you don't need to merge. All you need do is this:

# fetch from the default remote, origin
git fetch
# reset your current branch (master) to origin's master
git reset --hard origin/master

I'd personally recommend creating a backup branch at your current HEAD first, so that if you realize this was a bad idea, you haven't lost track of it.

If on the other hand, you want to keep those commits and make it look as though you merged with origin, and cause the merge to keep the versions from origin only, you can use the ours merge strategy:

# fetch from the default remote, origin
git fetch
# create a branch at your current master
git branch old-master
# reset to origin's master
git reset --hard origin/master
# merge your old master, keeping "our" (origin/master's) content
git merge -s ours old-master
Kijewski
  • 25,517
  • 12
  • 101
  • 143
Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 1
    In the second block of git commands there.. should there be a 'git fetch origin' after the second command? – David Tuite Jan 27 '11 at 10:50
  • @David: Yes, you should fetch from origin at some point. Sorry, I regarded it as implicit. – Cascabel Jan 27 '11 at 15:17
  • 2
    There's nothing that can be left implied when it comes to me and git ;-). Seriously though, thanks a million. Your answer's are exactly what I was looking for. – David Tuite Jan 27 '11 at 15:23
  • 1
    Will this work if origin is actually ahead? as in, can I also use it if I don't have any commits ahead, and in fact the branch can be fast-forwarded? – Jared Forsyth Oct 12 '13 at 23:37
  • This worked to resolve a file naming case conflict on windows. – Will B. Dec 19 '16 at 14:07
  • Why create a back-up? if you screw-up can't you just rely on the reflog to "go back in time" so to speak? – Coder Guy Sep 25 '18 at 21:05
  • Now it's called `origin/main`, not `origin/master` anymore. – bixiou Sep 28 '22 at 20:51
161

You can either use the answer from the duplicate link pointed by nvm.

Or you can resolve conflicts by using their changes (but some of your changes might be kept if they don't conflict with remote version):

git pull -s recursive -X theirs
Antoine Pelisse
  • 12,871
  • 4
  • 34
  • 34
  • 3
    Doesn't seem to be working for me. I get "error: unknown switch `X'" using git git version 1.5.6.5. Do I need to upgrade to an unstable version? – David Tuite Jan 24 '11 at 18:52
  • Also, Antoine, if you want to take origin's version of everything, not just conflicted content, you can - see my answer. – Cascabel Jan 24 '11 at 21:31
  • And finally, nvm's answer is not a duplicate. That wasn't an instance of merge conflicts (content tracked on both sides, with differences) but rather a merge that would overwrite untracked content. – Cascabel Jan 24 '11 at 21:32
  • Yes, I like your answer. Very interesting use of the `ours` strategy. – Antoine Pelisse Jan 25 '11 at 05:42
  • The use of the `ours` strategy is more obvious if you remember that the right direction to merge is almost universally from topic branch into master. – Cascabel Jan 25 '11 at 16:52
  • Sorry when I said 'unstable' all I meant was that there doesn't seem to be a more recent stable release of git in the Debian packages repository: http://packages.debian.org/lenny/git-core – David Tuite Jan 27 '11 at 10:49
  • 2
    @David You can get a recent version of git for debian from http://backports.debian.org/ – Arrowmaster Jan 27 '11 at 21:12
  • `-s recursive` [is the default](https://stackoverflow.com/questions/10697463/resolve-git-merge-conflicts-in-favor-of-their-changes-during-a-pull#comment38848036_21777677), so `git pull -X theirs` is enough. – Cees Timmerman Sep 21 '15 at 12:52
  • 2
    This is exactly what I was looking for! – micahblu Jul 15 '16 at 23:28
  • 2
    @CeesTimmerman Not true, at least in latest git. `X` option is passed through to merge strategy, which is only `recursive` if merging two heads, so your command will complain `"Could not find merge strategy 'theirs'. Available strategies are: octopus ours recursive resolve subtree."` - it's a shame, because `X` can be set in config (e.g. `git config pull.twohead theirs`) but `s` cannot. – OJFord Jan 13 '17 at 14:53
  • Unfortunately this doesn't work for me. I still have: `error: Your local changes to the following files would be overwritten by merge: file.txt Please commit your changes or stash them before you merge.` – Groosha Jul 16 '20 at 16:18