堆叠式拉取请求：从 fork 仓库到父仓库的合并请求。

Question

在从分支到主仓库进行PR时，如何使用堆叠式Pull Requests模式？

当我们需要将一个大的功能拆分成小的可审查的PR时，我经常使用这种模式。在一个仓库中，只需要在子分支之间进行PR，这非常简单。但是当我想要在不同的仓库之间创建PR时，我无法找到如何实现它。

例如，我想创建一个修复时间轴组件制表顺序的PR，但这个更改取决于修复侧向箭头和菜单按钮焦点性的PR。在单个仓库中，我会有这样的PR依赖关系结构：

1. master <- 侧向箭头修复
2. 侧向箭头修复 <- 菜单修复
3. 菜单修复 <- 制表修复

但是跨仓库 PR 只允许我选择 master 分支作为目标。这导致有 3 个 PR：

1. master <- sideways-fix
2. master <- menu-fix
3. master <- tabbing-fix

最后一个 PR 会重叠前面的两个 PR 的更改，使它更大且难以审核。

- Oleksandr Danylchenko

---

只需在前两个评论中添加注释即可开始第一个评论。或者建议逐个提交进行审查。 - Ôrel

谢谢，@Ôrel，这听起来很合理！我在想是否有一种方法可以避免人为因素，并且仅在Github级别上显示实际更改的内容，而不是继承的提交。 - Oleksandr Danylchenko

Answer 1

虽然这并不是直接支持的功能，但自2021年10月以来，正在进行一个“拉取请求合并队列有限测试版”的 Beta测试（现在，2023年2月，已经进入GA：一般可用性）。

它主要是验证并行地合并被标识为“准备好合并”的不同拉取请求的不同组合，以便拉取请求可以高效地合并，而且没有今天存在的合并之间的典型延迟。

因此，虽然不完全符合您的使用情况，但相似，因为您不必在合并之前重新定位一个PR。

在客户端上，您可以使用 realyze/pr-train 来帮助：

git pr-train 可帮助您管理PR链，当您需要将一个长PR拆分成较小的PR时。

如果您有一连串的PRs，则 git pr-train：

确保当您修改它们中的任何一个时，链中的所有分支都得到更新 为您创建GitHub PR，附带目录

- VonC