在GitHub上强制执行最新的拉取请求 [英] Enforce up-to-date pull requests on GitHub

问题描述

我们的团队在GitHub上拥有一个master分支以及其他一些功能分支，最终需要将它们合并回master.

Our team has a master branch on GitHub and several other feature branches that eventually need to be merged back to master.

在GitHub上创建请求请求之前，应该怎么做才能确保功能分支是最新的?我们可以在master分支上实现某种锁，以在创建Pull Requests之前实施最新的功能分支吗?

What should one do to ensure that the feature branch is up to date, before a Pull Request is created on GitHub? Is there a sort of lock that we can implement on the master branch to enforce up-to-date feature branches before Pull Requests can be created?

推荐答案

GitHub的分支保护可能要求分支合并之前是最新的，但创建之前不需要.这是有道理的.考虑:

GitHub's branch protection can require branches to be up to date before they're merged, but not before they're created. This makes sense. Consider:

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

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

Here, both feature-1 and feature-2 are up to date with respect to master. If the restriction required pull requests to be up to date when they're created we can create a PR for each branch.

但是当这些PR之一合并时会发生什么?

But what happens when one of those PRs gets merged?

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

现在 feature-2 不再是最新的.它的公关应该怎么办?自从它是最新的以来，我们不做任何事情吗?我们是否会使PR完全无效，并要求创建一个新的PR?我们应该在任何给定时间只开放一个公关吗?

Now feature-2 is no longer up to date. What should happen to its PR? Do we do nothing since it was up to date when it was created? Do we invalidate the PR entirely and require a new one to be created? Should we only ever have a single PR open at any given time?

GitHub的系统在合并时适用.这样，可以在准备合并之前创建PR(例如PR草案)，并且可以安全地引发有意义的讨论，而不是匆忙进行.这也意味着我们不必处理上一个问题.

GitHub's system applies at merge time. This way PRs can be created before they're ready for merging (e.g. draft PRs) and can safely generate meaningful discussion rather than being rushed through. It also means that we don't have to deal with the previous question.

这篇关于在GitHub上强制执行最新的拉取请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！