Github 究竟什么时候检查拉取请求的合并冲突？答案

【问题标题】：When exactly does Github check for merge conflicts on pull request?Github 究竟什么时候检查拉取请求的合并冲突？
【发布时间】：2019-11-01 18:56:55
【问题描述】：

这听起来像是一个非常简单的问题。

我 3 天前在 Github 上提出了 PR，在创建 PR 时没有合并冲突。今天打开PR链接，依然没有合并冲突。 PR reviewer说我应该先rebase本地再push代码，然后Github会检查合并冲突。我的观点是，Github（网站）检查所有其他 PR 合并时的合并冲突，即当 master 分支代码更新时，所以我不需要在本地重新设置基准然后推送代码。

我是对的吗？审阅者批准 PR 是否安全，因为它在 Github.com 上没有显示任何合并冲突，而无需我在本地重新编写代码。

如果有人也可以发布 Github 开发人员定义流程的官方文档，我将不胜感激。

【问题讨论】：

是的，如果 github 没有显示任何合并冲突，则没有需要重新设置基准。在拉取请求中，会比较要合并的分支的当前 HEAD，因此如果没有显示冲突，则可以在两个分支的当前状态下执行合并。话虽如此，如果项目常见的工作流程是在合并前变基，你应该坚持下去。

标签： git github merge git-merge git-merge-conflict

【解决方案1】：

PR 审稿人说我应该先在本地 rebase，然后再推送代码

拉取请求审阅者错误。让我们看看我的拉取请求有 2 个提交（https://github.com/telerik/kendo-ui-core/pull/5102）

简单而现实地思考：冲突，这意味着您不能在同一行代码中保留来自 2 个开发人员的 2 个不同内容。 开发者 Bob 的代码 sn-p 和开发者 John 的代码 sn-p 不能站在同一行。 解决冲突，这意味着选择 Bob 的代码或 John 的代码。

了解合并冲突：https://docs.microsoft.com/en-us/azure/devops/repos/git/merging?view=azure-devops&tabs=visual-studio#understand-merge-conflicts

【讨论】：

感谢您的确认和举例。