注意
此功能以公共预览版提供，可能会发生更改。
大型拉取请求难以查看和创建瓶颈，尤其是在短时间内生成大量代码时。 随着拉取请求大小的增加，评审质量也会下降。 审阅者可能会忽略结果、错过问题或拖延并退出拉取请求，直到拉取请求变得过时并发展合并冲突。
堆积拉取请求使大型代码更改可查看。
堆栈是同一存储库中的一系列拉取请求，每个拉取请求都面向其下方的拉取请求的分支，形成位于单个分支（通常是主分支）上的有序链。 获取一组较小的拉取请求，而不是一个大型拉取请求。 由于每个拉取请求都有自己的重点差异，因此团队成员可以独立评审和批准每个层。
本教程逐步讲解如何使用堆积拉取请求在可单独审阅的层中生成功能。 对于我们的示例，我们将考虑如何将用户身份验证添加到应用。 我们将使用扩展名gh stack。GitHub CLI
先决条件
若要遵循本教程，需要安装和GitHub CLIgh stack扩展。 需要具备以下条件：
- GitHub CLI （
gh） 2.90.0 或更高版本，以及 Git 2.20 或更高版本。- 使用 GitHub CLI. 进行身份验证
gh auth login。
- 使用 GitHub CLI. 进行身份验证
- 可以推送到的 GitHub 存储库。
在 GitHub CLI中，安装 gh stack 扩展。
gh extension install github/gh-stack
1.在生成代码之前设计堆栈
一个好的堆栈就像建造一栋房子：从坚实的基础开始，框架墙壁，安装电线，然后完成干墙。 每个层都依赖于下面的层。 最后，审阅者应该能够从底部到顶部读取拉取请求，并遵循该功能的开发。
- 将特征拆分为层。 每个层应该是一个一致的更改，可以自行审查。
- 保持每个层足够小，使其拉取请求是快速读取的。 如果层感觉它需要一个较长的描述来审查，它可能太大。
- 自行决定边界。 你拥有堆栈的形状。
- 按依赖项对层进行排序。 基础更改位于底部。 依赖于它们的任何内容都会更高。 对于身份验证，可能是：
- 第 1 层：数据模型和迁移
- 第 2 层：CRUD 终结点
- 第 3 层：JWT 中间件和防护
- 第 4 层：集成和单元测试
2. 首先生成底层
使用基础启动堆栈。 上述所有内容都取决于正确获取此层。
- 创建堆栈并根据计划生成第一层。 使用前缀创建它
gh stack init BRANCH-NAME-1，请考虑使用前缀来保持分支名称整洁。 - 在继续操作之前，请查看更改。 底层的错误传播到其上方的每一个分支，因此请在继续操作之前进行评审。
3.将每个新代码层堆叠在顶部
建立基础后，一次生成一层特征的其余部分。
- 添加下一层，并在下面的层上下文中实现它。 将分支添加到堆栈
gh stack add BRANCH-NAME-NEXT顶部，并在其中提交工作。 - 如果层开始增长太大，请考虑它是否偏离了计划，或者你实际上需要两个层而不是一个层。
- 在进行时为每个层创建新分支，因此每个分支都保持一个干净的独立差异。
- 准备好创建拉取请求时，请使用
gh stack submit.. - 让每个拉取请求单独站出来。 重点标题和对层的简洁、有意义的描述通常足够。
4. 在请求评审之前自行查看拉取请求
每个层都很小，使自我审查也更容易。 在涉及队友之前，对每个分支执行传递。 审阅者应收到你已信任的更改。
- 在请求评审之前，在每个分支上运行测试、linters 和代码扫描，根据标准检查每个层。
5. 从底部开始请求堆栈评审
生成层后，审阅者会获得较小的差异，而不是大墙代码。
- 如果依赖项已强集成，请要求从堆栈底部开始的评审，以便可以在后续评审之前将更改集成到堆栈上。
- 如果需要不同层的单独人员进行评审，审阅者可以并行工作。 一个人可以查看数据模型，而另一个人则通过评审整个功能来评审终结点，这两个人员都不进行人工检查。
6. 循环访问反馈
单独查看反馈位于层上，而不是整个功能。 堆栈允许你就地修复正确的层，并将更改向上传递。
- 修改标记为审阅者的层。 移动到右侧分支，进行更改，并在其中提交。
- 将每个修补程序保留在它所属的层中。 错误分支上所做的更改可能会混淆并创建错误。
- 使用
gh stack down或gh stack up``gh stack checkout BRANCH-NAME. 然后，提交更改，运行gh stack rebase --upstack以重新定基上述分支，然后gh stack push携带堆栈上的更改。
7. 从底层合并
堆栈按顺序合并，从指向主分支的层开始。 一次性合并层或逐个合并层，GitHub自动将下一层重新定位到主层。
- 一次从下到上合并堆栈，或者从堆栈中的任意位置合并堆栈，合并请求下方的所有分支都将从下到上合并。
- 每个层的差异与其父级完全相同，只有基本更改，因此一次可以轻松合并层，而不会影响正在进行的工作或评审。
- 使用合并队列，以便在每个层获得批准后按顺序合并，并且其检查通过。 无需一次性等待整个堆栈。
一旦顶层合并，整个特征就已落地。 每一件都更有效地审查为一个小的故意更改，而不是一个大型拉取请求。