在 GitHub 上强制执行最新的拉取请求答案

【问题标题】：Enforce up-to-date pull requests on GitHub在 GitHub 上强制执行最新的拉取请求
【发布时间】：2019-04-20 01:40:53
【问题描述】：

我们的团队在 GitHub 上有一个 master 分支和其他几个最终需要合并回 master 的功能分支。

在 GitHub 上创建 Pull Request 之前，应该如何确保功能分支是最新的？是否可以在主分支上实施某种锁，以在创建拉取请求之前强制执行最新的功能分支？

【问题讨论】：

【解决方案1】：

GitHub 的分支保护可以要求分支在被合并之前是最新的，但在创建之前不需要。这是有道理的。考虑：

*---*---*---*  [master]
            |\
            | *---*---*  [feature-1]
             \
              *---*  [feature-2]

这里，feature-1 和 feature-2 都相对于 master 是最新的。如果限制要求拉取请求在创建时是最新的，我们可以为每个分支创建一个 PR。

但是当其中一个 PR 被合并时会发生什么？

*---*---*---*-----------*  [master]
            |\         /
            | *---*---*  [feature-1]
             \
              *---*  [feature-2]

现在feature-2 不再是最新的。它的公关应该怎么办？因为它在创建时是最新的，所以我们什么都不做吗？我们是否完全使 PR 无效并需要创建一个新 PR？我们应该在任何给定时间只打开一个 PR 吗？

GitHub 的系统在合并时应用。通过这种方式，可以在 PR 准备好合并之前创建它们（例如 draft PRs），并且可以安全地产生有意义的讨论，而不是匆忙通过。这也意味着我们不必处理前面的问题。

【讨论】：

您可以通过在合并其中一个 PR 时自动更新分支来伪实现此目标。例如，在本例中，当 feature-1 分支合并到 master 中时，您可以触发 Github Action 以自动所有待处理的拉取请求。还有一些工具可以为您做到这一点。我过去使用过的一种叫做mergequeue.com。该工具还支持在合并 PR 时使所有分支保持最新的功能。

【解决方案2】：

我什至不确定您是否需要任何此类功能。如果某个功能分支与master 分支确实不同步，以至于合并 PR 会导致合并冲突，那么 GitHub 将标记该拉取请求并拒绝自动完成它。

当然，作为实践，大多数开发人员都会从经验中学到，与master 合并/变基是一个普遍的好习惯。但是，这些事情已经被 GitHub 强制执行了，至少在默认情况下是这样。

【讨论】：