有时，当我尝试将头叉合并到我的基叉中，或将我的基叉合并到头叉中时，我在GitHub上收到以下消息:
如果有任何冲突，我如何看待冲突？
我已经阅读了大约10个带有各种命令的不同示例，但是由于存在基，叉，分支等的不同名称，因此我无法确定示例中的名称适用于我的情况。
毕竟，我不相信没有可以键入的命令来查看冲突，编辑冲突并继续进行合并。
如果有，我还没有找到。
最佳答案
这意味着如果上游所有者不必解决合并冲突，则无法将您的拉取请求合并到上游。
解决方案是让您从上游获取数据，然后从上游解决合并冲突。此时，如果您从理论上解决了上游的冲突，然后创建了您的请求，则上游将能够自动合并到您的请求中，而不会发生任何冲突(前提是您之间在上游没有本地本地解决上游的提交问题)合并冲突并合并到本地/分支中，然后创建拉取请求)。
让我们以GitHub作为远程回购存储的示例。
OriginalAccount \ repo1 -说这是原始存储库(我们将其称为“上游”)
YourAccount \ repo1 -这将是您存储库的分支(通常是“原始”远程数据库)
repo1 local-这是存储库的本地副本。
当您从 YourAccount \ repo1 创建到 OriginalAccount \ repo1 (实际上是从源到上游)的拉取请求时，看到无法自动合并的消息意味着 OriginalAccount \ repo1 已提交了 Yourrecount 没有(提交的最有可能在您 fork 后提交的提交)。
此处的解决方案是从上游获取本地存储库(从 OriginalAccount \ repo1 到本地存储库)，并在本地解决任何合并冲突。然后将提交推送到 YourAccount \ repo1 。此时，您应该能够创建应该自动合并到 OriginalAccount \ repo1 的拉取请求。
注意:尽管大多数Git服务不会阻止您继续进行请求请求，而请求请求需要上游贡献者解决合并冲突，但是确保您的请求请求没有冲突地合并是一种良好的做法和良好的礼节。这样思考，您应该进行合并冲突解决工作，而不是让上游贡献者从您的贡献中进行这项工作。