我用了git pull并发生了合并冲突：
1
2
3
| unmerged: _widget.html.erb
You are in the middle of a conflicted merge. |
我知道文件的另一个版本是好的，而我的版本是坏的，所以应该放弃所有的更改。我该怎么做？
- 我意识到这是一个非常古老的问题，但是您是想中止整个合并，而不合并正在合并的分支，还是忽略这个文件作为更大合并的一部分，让所有其他文件正常合并？对我来说，你的头衔意味着前者，你的问题主体想要后者。答案两者兼而有之，但没有明确说明。
- 我在提交时遇到了类似的情况，说自动合并失败了；修复冲突，然后提交结果：[rejected] gh-pages -> gh-pages (non-fast-forward)。
- Gwyn，在这里选择一个可接受的答案可能很有用。最受欢迎的一个比一些最新的解决方案要安全一点，所以我认为这将有助于突出其他解决方案：)
由于您的pull不成功，那么HEAD是您分行最后一次"有效"承诺：
你想要的另一件事是让他们的改变超越你的改变。
Git的旧版本允许您使用"他们的"合并策略：
1
| git pull --strategy=theirs remote_branch |
但是，正如Git维护人员Junio Hamano在这条消息中所解释的那样，这已经被删除了。如链接中所述，您可以这样做：
1
2
| git fetch origin
git reset --hard origin |
- 你可以通过这样做，而不是进行硬重置：git fetch origin->git reset origin (soft reset, your changes are still present)->git checkout file_to_use_their_version_of another_file (steamroll your own changes back to match the origin)，我不再使用git pull。因为在我最新的代码和源代码之间的斗争中，源代码应该总是赢的，我总是git fetch和git rebase origin。这实际上使我的合并和冲突变得很少和遥远。
- 我同意。我还喜欢先获取数据，然后检查上游变化(git log ..@{upstream}或git diff ..@{upstream})。之后，像你一样，我会重新安排我的工作。
- 除此之外，如果您还有一些要清理的未跟踪文件，我建议运行"gitclean-f"。
- 不是git reset --hard origin，而是git branch -r(选择分支名称)，git reset --hard remote/branch为我工作。
- 正如最新的答案所指出的，从1.6.1版开始，可以使用"git reset--merge"。
- 我用git merge -X theirs remote_branch代替git pull --strategy=theirs remote_branch，因为theirs看起来像recursive的选择。
- 没有策略theirs。
- @MLT，theirs确实是递归的一个选项，根据文档，它不作为自己的策略存在(在当前的git中)。
- git merge --abort更可取。
- 向下投票，优先考虑卡尔的更有力/更简单的答案。
- 你的埃多克斯1〔17〕很漂亮。谢谢
- 以东x1〔0〕，接着是以东x1〔19〕。顺便说一下，我使用的是Git 2.13.6版(Apple Git-96)
如果您的Git版本大于等于1.6.1，则可以使用git reset --merge。
另外，正如@michael johnson所提到的，如果您的Git版本大于等于1.7.4，您还可以使用git merge --abort。
和往常一样，在开始合并之前，请确保没有未提交的更改。
从Git合并手册页
当存在MERGE_HEAD时，git merge --abort相当于git reset --merge。
合并进行中，出现MERGE_HEAD。
另外，对于开始合并时未提交的更改：
如果在开始合并之前您不想提交更改，只需在合并之前提交git stash，在完成合并或中止合并之后提交git stash pop。
- 有趣-但是手册让我害怕。什么时候适合使用？您何时需要指定可选的？γgim力矩：-O
- 当您希望从一开始重新进行合并时，通常会使用这个方法。我从未需要自己指定可选提交，因此默认值(no optional)很好。
- 我希望这个答案有更多的选票！在这一点上，它在许多情况下似乎是最相关的解决方案。
- 因为Gitv1.7.4Git合并——Abort也可以工作。
- 即使有未限制的更改，Git也能够在合并之前恢复状态。好极了！
- git merge --abort是git reset --merge的同义词吗？这个名字当然更有意义，但是它有相同的功能吗？
- 埃多克斯1〔23〕救了我的培根。太神了！
- 这应该是公认的答案，因为它已经有一段时间了。
- 嘿@carl，你能删掉这个答案吗？很多人都很困惑，包括我自己。git merge--abort是正确的答案，应该在顶部。
- git merge --abort不适用于章鱼合并冲突，只有git reset --merge起作用。
- @里兹：你提供什么证据来支持你的索赔？
Abort the current conflict resolution process, and try to reconstruct
the pre-merge state.
If there were uncommitted worktree changes present when the merge
started, git merge --abort will in some cases be unable to
reconstruct these changes. It is therefore recommended to always
commit or stash your changes before running git merge.
git merge --abort is equivalent to git reset --merge when
MERGE_HEAD is present.
http://www.git-scm.com/docs/git-merge
- 这是从Git v1.7.4开始提供的。它是git reset——合并的别名。
- 不适用于章鱼合并冲突。
我想是你需要的。
注意，git revert的意思与svn revert的意思非常不同，在subversion中，revert将放弃(未提交的)更改，将文件从存储库返回到当前版本，而git revert则"撤消"提交。
git reset应该与svn revert相当，也就是说，放弃你不想要的改变。
在这个特定的用例中，您并不真正希望中止合并，只需要以特定的方式解决冲突。
也不需要用不同的策略重置和执行合并。Git已经正确地突出显示了冲突，接受其他方面更改的要求仅适用于此文件。
对于冲突中未合并的文件，git将提供索引中该文件的公共基础、本地和远程版本。(这是git mergetool在3路Diff工具中读取它们的地方。)您可以使用git show查看它们。
1
2
3
4
5
6
7
8
| # common base:
git show :1:_widget.html.erb
# 'ours'
git show :2:_widget.html.erb
# 'theirs'
git show :3:_widget.html.erb |
解决使用远程版本逐字冲突的最简单方法是：
1
2
| git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb |
或者，当git大于等于1.6.1时：
1
| git checkout --theirs _widget.html.erb |
- 谢谢你的提示。不过，这不是一个糟糕的git用户界面的味道吗？
- @彼得：我不相信。通过简单的选项，使用一些基本命令，可以获得所需的结果。你有什么改进建议？
- 我认为git 1.6.1命令很有意义，而且很好。这正是我想要的。我认为pre-1.6.1解决方案并不完美，需要了解Git的其他部分，这些部分应该与合并解决过程分开。但是新版本很棒！
它如此简单。
当遇到这种类型的问题时，git本身会向您显示解决方案，并运行git status命令。
希望这能帮助人们。
由于评论认为git reset --merge是git merge --abort的别名，因此值得注意的是，考虑到存在MERGE_HEAD的情况，git merge --abort只相当于git reset --merge。这可以在合并命令的git帮助中读取。
1
| git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present. |
合并失败后，在没有MERGE_HEAD的情况下，可以用git reset --merge撤消合并失败，但不一定用git merge --abort撤消合并失败，因此它们不仅是同一事物的新旧语法。
我个人认为，对于类似于上述场景的场景，git reset --merge更加强大，并且总体而言，合并失败。
- 这里的"失败合并"实际上是什么意思？是否与冲突或其他内容合并？或者换个说法：什么时候合并头不存在？我的后续问题是更好地理解"git reset——merge"的用法。
- 对我来说是一场混乱，但对我来说却是一场混乱。
如果您最终遇到合并冲突，并且没有任何要提交的内容，但是在应用下面提到的所有命令之后仍然显示合并错误，
1
2
3
4
| git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch origin
git reset --hard origin |
请删除
.git\index.lock
文件[Cut Paste to some other location in case of recovery]然后根据您想要的版本输入下面的任何命令。
1
2
| git reset --hard HEAD
git reset --hard origin |
希望有帮助！！！！
自Git 1.6.1.3以来，git checkout已经能够从合并的任何一边签出：
1
| git checkout --theirs _widget.html.erb |
保留工作副本状态的另一种方法是：
1
2
3
| git stash
git merge --abort
git stash pop |
我通常建议不要这样做，因为它实际上就像在Subversion中合并一样，因为它会在下面的提交中丢弃分支关系。
- 当我意外地合并到一个GitSvn分支时，我发现这种方法很有用，它不能很好地处理这个问题。当使用Git SVN跟踪分支时，壁球合并或樱桃选取效果更好。实际上，我的解决方案将合并变成事实之后的挤压合并。
我发现以下内容对我有效(将单个文件还原为预合并状态)：
1
| git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset* |