在严格的基础分支保护下，是否可以通过推送合并每个分支的提交来关闭 Github 上的多个 PR？

Question

我正在参与 Github Enterprise 服务器上的代码库的开发，并且为

master

提供了分支保护。我打开了 3 个 PR，每个 PR 都有自己的修复/功能分支提示，这些提示在某一时刻与

master

上的同一提交不同，并且所有 PR 都已获得批准，并且每个分支上的所有提交都已签名.

因为我确实并且希望继续直接使用 Git，并且尽可能少地与 Github 的网页打交道，所以我想我可以通过在本地合并所有分支（每个 PR 一个）来关闭 PR。单个新提交，这显然是毫不费力的 - 我现在有了

master

（本地）的新提示，它具有三个父提交 - 一个用于其 PR 的每个分支提示。

当我尝试使用单个

master

将

git push origin master

推送到 Github 时，特别是 Github 拒绝配合，我收到以下致命错误：

Enumerating objects: 26, done.
Counting objects: 100% (25/25), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.43 KiB | 1.43 MiB/s, done.
Total 6 (delta 4), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Changes must be made through a pull request.
To github.com:foo/bar.git
! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'github.com:foo/bar.git'

我的同事告诉我，我必须“按顺序”将每个 PR（本地）与其自己的提交合并，以便代替当前的（使用

master

我似乎无法推送）：

*---.   b409f01 (master)
|\ \ \
| | | * 92f9834 (PR #3)
| |_|/
|/| |
| | * 0547677 (PR #2)
| |/
|/|
| * e6aa276 (PR #1)
|/
* fb00b60 (origin/master)

...我对 Github 更“顺从”（我必须承认，对我来说更不顺从）以下拓扑：

*-. 92f9834' (merged PR #3, master)
*. \ 0547677' (merged PR #2)
* \ \ e6aa276' (merged PR #1)
|\ \ \
| | | * 92f9834 (PR #3)
| |_|/
|/| |
| | * 0547677 (PR #2)
| |/
|/|
| * e6aa276 (PR #1)
|/
* fb00b60 (origin/master)

（与

--no-ff

合并完成）

...推送应该会成功，因为在这种情况下，Github 能够推断出合并提交和 PR 之间的“正确”关系。

这是真的吗？

我确实模拟了第二个拓扑变体，其中我“按顺序”合并每个 PR 的尖端 - 首先将第一个 PR 合并到

master

，然后推送

master

（这按预期关闭了 PR），然后 [将]第二个PR合并到

master

中，然后尝试推送它，这已经是推送失败的地方，并出现与上述相同的错误消息。所以我不确定拓扑是否一定会影响到这一点。

我想一般来说我想知道 Github 如何促进 Git 允许我的分布式工作流程，比如说 3 个开放 PR，它们可能有也可能没有相同的作者（阅读：并行开发），以及一名主要维护者将所有内容合并到

master

？ Git 显然很好地促进了这一点，通过我首先描述的那种我在本地开发的拓扑（但无法推送），虽然我了解分支保护的好处（毕竟我正在使用它），但我会吗？需要停下来，例如按顺序重新调整每个 PR，以合并所有内容？

Answer 1

是的，我的看法是，在合并到 master 之前，您需要重新调整（或合并）ech PR。

这就是 PR 维护者需要定期针对 master 更新分支的模型，以便合并模型更简单。

一种选择是创建一个合并分支 PR，将各个 PR 全部合并在一起。

一般来说，我会避免任何这种情况，因为出现的任何问题的复杂性都会大大增加。我坚持使用简单的 git 模型，在合并之前将每个分支更新为 master。我喜欢推动每个合并并看到所有测试都通过。在CI