我发现解决拉取请求冲突的方法不是很直观。有人能给一些进一步的解释或推理吗？
场景：
两名开发人员同时打开了两份PR，一份是分支feature-1的PR1，另一份是分支feature-2的PR2，他们都编辑了同一个文件，这将导致冲突。
PR1首先成功合并。但PR2现在有冲突要解决。解决此问题的"正式"方法是：
1.在local中，将最新的main和meregemain拉到branchfeature-2（并在此解决冲突）;
1.将分支特性-2推到远程，现在PR2可以进行。
网络如下所示
- 我的问题是，为什么我们不能通过将feature-2合并到main*中来解决冲突（即，在此步骤中直接解决冲突）？
相比之下，在"官方"的方式中，我们必须将main合并到feature-2，然后再合并回main。这不直观，而且往往会创建混乱的提交历史。我能想到的唯一原因是PR工作流的设计者认为解决冲突是功能开发人员的责任，而不是main分支所有者的责任。
我检查的所有教程都显示了"官方"工作流程，我相信这是常见的做法。但我发现它不是很直观。我期待更多的推理和有见地的评论。
3条答案
按热度按时间jecbmhm31#
当你和许多其他用户一起工作时，比如你在公司的同事，仓库通常有一个主副本，位于gitlab这样的服务器上，你通常不能直接把东西推送到主分支，你只能要求服务器把一个分支合并到主分支。但这只有在没有合并冲突的情况下才有效。2所以你必须解决分支上的合并冲突，这样这个分支才能被合并而没有冲突。
有时候服务器上也会有一个限制，只允许快速合并。这意味着，只有当你的分支在合并后与主分支的预期状态没有区别时，你才可以合并。
如果你独自在一个git仓库工作，并且对所有的东西都有完全的访问权限，那么你完全可以合并到main并在合并的同时解决冲突。
wrrgggsh2#
持续部署工作流通常会在启用绿色的“Merge pull request”按钮之前对PR分支的代码进行单元或功能测试的检查，因此它们禁止推送
main分支，以防止提交或合并未测试的代码。csbfibhn3#
实际上，有时候你可以在目标分支上执行合并操作。合并请求功能并不是Git固有的一部分，因此它依赖于工具，但有些工具直接在UI中提供有限的合并冲突解决方案，例如：
**旁注：**要在本地解析，您不必将目标合并到功能分支中。在大多数工作流中，您可以首先将功能分支重定到目标上，以避免在功能分支上提交新的合并。（显然，您不能在共享分支上执行此操作，但通常对于“功能”分支来说是可以的。）