有时当我尝试将head fork合并到我的基础fork中，或者将我的基础fork合并到head fork中时，我在GitHub上收到以下消息：
“无法自动合并。别担心，您仍然可以创建拉取请求。”
如果有冲突，如何查看冲突？
我已经阅读了大约10个不同的例子和各种命令，但我不知道在我的情况下示例中的名称适用于基础，分支，分支等的不同名称。
在完成所有这些之后，我无法相信没有可以键入的命令来查看冲突，编辑冲突并继续合并。 如果有，我还没有找到它。
答案 0 :(得分：23)
这意味着您的拉取请求无法合并到上游，而上游所有者不必解决合并冲突。
此处的解决方案是让您从上游进行提取，然后解决上游的合并冲突。此时，如果您理论上解决了来自上游的冲突然后创建了拉取请求，则上游将能够自动合并您的拉取请求而不会发生任何冲突（前提是您在本地解析上游之间没有上游提交合并冲突并合并到本地/ fork，然后创建拉取请求。）
让我们使用GitHub作为远程仓库商店的例子。
OriginalAccount \ repo1 - 说这是原始存储库（我们将其称为＆＃34;上游＆＃34;）
YourAccount \ repo1 - 这将是您对存储库的强制（这通常是＆＃34;来源＆＃34;远程）
repo1 local - 这是您的本地存储库副本。
从 YourAccount \ repo1 创建拉取请求到 OriginalAccount \ repo1 （几乎从 origin 到上游 >），通过自动合并的消息意味着 OriginalAccount \ repo1 提交 YourAccount \ repo1 没有提交（提交你分叉之后很可能被推了。
这里的解决方案是从上游获取到本地存储库（从 OriginalAccount \ repo1 到本地存储库）并在本地解决任何合并冲突。然后将您的提交推送到 YourAccount \ repo1 。此时，您应该能够创建应该能够自动合并到 OriginalAccount \ repo1 的拉取请求。
注意：尽管大多数Git服务都不会阻止您继续执行需要上游贡献者解决合并冲突的拉取请求，但确保您的拉取请求是一种良好的做法和良好的礼仪合并没有冲突。想想这样，您应该进行合并冲突解决工作，而不是让上游贡献者从您的贡献中完成这项工作。
答案 1 :(得分：11)
假设有你的分支和主分支。您希望将来自您的分支的更改合并到主服务器以供其他人查看，但是其他人在此期间对主服务器执行了相互冲突的更改（例如合并其PR）。在创建PR之前，将master合并到您的分支（即以相反的方式进行合并）通常很有用。
在命令行中，您可以：
git checkout master
git pull
git checkout your-branch
git merge master
现在您可以看到冲突列表。按照从git获得的消息来解决冲突。您可以使用自己喜欢的工具，因此更容易。最后，你提交并推送。当您重新创建PR时，应该没有冲突。
答案 2 :(得分：1)
这样做的简单方法是以这种方式使用Github：
在Github中选择分支选项卡，单击合并视图按钮，将您的头叉拖到左侧框，将基叉拖到右侧框。 单击“合并分支”按钮。 选择更改选项卡。 选择每个有冲突的文件。见'＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt; 在外部查看器中编辑文件以保留headfork代码并将其添加到其中。 单击文件上的保存。 单击“提交到”按钮。 点击同步。 转到Git网站，尝试再次将基础分支合并到head fork。 它不应再显示原始消息
答案 3 :(得分：0)
当你的代码被合并到repo中时，你会遇到冲突。 如果您的拉取请求被接受，则由回购经理来解决它们。