解决 Git 合并冲突
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7694467/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Resolving Git merge conflicts
提问by g_thom
A Git repository has been cloned on several developers' local machines. Some changes have been made to the code in the repository. We're now getting the error:
一个 Git 存储库已被克隆到多个开发人员的本地机器上。对存储库中的代码进行了一些更改。我们现在收到错误：
error: Your local changes to the following files would be overwritten by merge:
public_html/sites/file
public_html/sites/file1.txt
public_html/sites/file2.txt
Please, commit your changes or stash them before you can merge.
Aborting
I've read quite a few threads online, and several different options have been suggested. One approach was run:
我在网上阅读了很多主题，并提出了几种不同的选择。运行了一种方法：
git stash
git pull
git stash pop
I think I understand the basic principle of stashing. My question is, is this a good solution, and could I run into any issues using this approach? I have a reasonable understanding of web development in general, but I'm a fairly basic Git users and wouldn't have a lot of ability to get myself out of trouble at this point.
我想我明白了 stashing 的基本原理。我的问题是，这是一个很好的解决方案吗，使用这种方法我会遇到任何问题吗？总的来说，我对 Web 开发有一个合理的了解，但我是一个相当基本的 Git 用户，在这一点上我没有太多的能力让自己摆脱困境。
采纳答案by kylben
git stashis perfectly legitimate, though as Greg said, for some reason fixing the conflicts can get strange. But they are still fixable, you won't actually fubar anything. The command as I know to re-apply the stash is git stash apply, though popmay be an alternative that I'm not aware of (or it could do something different, I don't know, so you probably want to use apply.)
git stash是完全合法的，尽管正如 Greg 所说，由于某种原因，修复冲突可能会变得奇怪。但它们仍然是可以修复的，你实际上不会对任何东西造成伤害。据我所知，重新应用存储的命令是git stash apply，尽管pop可能是我不知道的替代方法（或者它可以做一些不同的事情，我不知道，所以你可能想使用apply.）
Is there a reason you don't want to commit those changes before merging? Generally that's the right thing to do.
您是否有理由不想在合并之前提交这些更改？一般来说，这是正确的做法。
Another option is:
另一种选择是：
git stash
git checkout -b newwork
git stash apply
git commit ...
This creates a new branch, which will allow you to get your master up to date without conflicts, (checkout master again, then pull or fetch + merge). Then you can merge your branch back with (while still on master) git merge newwork. You can resolve the conflicts on master, while still retaining the work on newwork without any conflicts. This is a bit safer if you are worried about conflicts really screwing things up, but generally, conflicts are just part of the process, so don't worry too much about them.
这将创建一个新分支，这将允许您在没有冲突的情况下更新您的 master（再次签出 master，然后 pull 或 fetch + merge）。然后你可以将你的分支与 (while still on master) 合并 git merge newwork。您可以解决 master 上的冲突，同时仍然保留 newwork 上的工作而没有任何冲突。如果您担心冲突真的会把事情搞砸，这会更安全一些，但通常，冲突只是过程的一部分，所以不要太担心它们。
回答by Greg Hewgill
It's good practice to alwayscommit any local changes before pulling (merging) new code. If you don't commit, then Git doesn't know how you want to manage your local changes. Merge only with a clean working tree.
在拉取（合并）新代码之前始终提交任何本地更改是一种很好的做法。如果你不提交，那么 Git 不知道你想如何管理你的本地更改。仅与干净的工作树合并。
There may be conflicts in the merge, due to the same files being changed locally and by somebody else. In my experience, resolving conflicts from an actual mergeoperation is slightly simpler than resolving the same conflict from a stash popoperation.
由于在本地和其他人更改了相同的文件，因此合并中可能存在冲突。根据我的经验，解决实际合并操作中的冲突比解决stash pop操作中的相同冲突要简单一些。
回答by Narga
I have another solution:
我有另一个解决方案：
git reset --hard FETCH_HEAD
It works in almost cases.
它几乎适用于任何情况。
回答by MrBii
First you should:
首先你应该：
git checkout -- public_html/sites/file
git checkout -- public_html/sites/file1.txt
git checkout -- public_html/sites/file2.txt
Next step:
下一步：
git pull origin master
