拉取请求中堆栈 AI 生成的代码

大型拉取请求难以查看和创建瓶颈，尤其是在 AI 帮助短时间内生成大量代码时。 随着拉取请求大小的增加，评审质量也会下降。 审阅者可能会忽略结果、错过问题或拖延并退出拉取请求，直到拉取请求变得过时并发展合并冲突。

堆积拉取请求使大型代码更改可查看。

A stack is a series of pull requests in the same repository where each pull request targets the branch of the pull request below it, forming an ordered chain that lands on a single branch, typically your main branch. Instead of one large pull request, you get a set of smaller pull requests. Since each pull request has its own focused diff, teammates can review and approve each layer independently.

本教程逐步讲解如何将堆叠拉取请求与代理配合使用，以在可单独审阅的层中生成功能。 对于我们的示例，我们将考虑如何将用户身份验证添加到应用。 我们将使用 GitHub Copilot 命令行界面 (CLI) 和 gh-stack 代理技能。

先决条件

若要将 gh-stack 技能用于代理，首先需要安装和 GitHub CLIgh-stack CLI 扩展。 需要具备以下条件：

• GitHub CLI （gh） 2.90.0 或更高版本，以及 Git 2.20 或更高版本。
  • 使用 GitHub CLI. 进行身份验证gh auth login。
• 可以推送到的 GitHub 存储库。
• GitHub Copilot 命令行界面 (CLI) 已安装并登录。

在 GitHub CLI中 gh-stack ，安装扩展和技能。

gh extension install github/gh-stack
gh skill install github/gh-stack

1.在生成代码之前设计堆栈

一个好的堆栈就像建房子，从坚实的基础开始，框架墙壁，安装电线，然后完成干墙。 构建的每个层都取决于下面的层。 最后，审阅者应该能够从底部到顶部读取拉取请求，并遵循功能走到一起。

• 将特征拆分为层。 每个层应该是一个一致的更改，可以自行审查。
  • 保持每个层足够小，使其拉取请求是快速读取的。 如果层感觉它需要一个较长的描述来审查，它可能太大。
  • 自行决定边界，或处理 Copilot 计划。 无论哪种方式，你都拥有堆栈的形状。
• 按依赖项对层进行排序。 基础更改位于底部。 依赖于它们的任何内容都会更高。 对于身份验证，可能是：
  • 第 1 层：数据模型和迁移
  • 第 2 层：CRUD 终结点
  • 第 3 层：JWT 中间件和防护
  • 第 4 层：集成和单元测试

示例提示

• Propose a layered approach to add user authentication to this app. Order the layers by dependency, keeping each layer independently reviewable.
• Review my planned layers and flag any that are too large or that depend on a branch above them.

2. 首先生成底层

使用基础启动堆栈。 上述所有内容都取决于正确获取此层。

• 通知 Copilot 你将生成堆积拉取请求，并要求它基于计划生成第一层。 代理使用 gh-stack 技能创建堆栈的第一个分支。
• 如果希望自己创建堆栈，请使用前缀直接 gh stack init创建堆栈，以保持分支名称整洁，例如 gh stack init BRANCH-NAME-1。
• 在继续操作之前，请查看生成的更改。 底层的错误传播到其上方的每一个分支，因此请在继续操作之前进行评审。

示例提示

• Start the pr-stack and build only the first layer: the user data model and migration.
• Conduct a review of the generated code and confirm this branch contains only the data model and migration, and nothing that belongs in a later layer.

3.将每个新代码层堆叠在顶部

建立基础后，一次生成一层特征的其余部分。

• 要求 Copilot 添加下一层并在下面的层上下文中实现它。 代理会将分支添加到堆栈顶部，并在其中提交工作。
• 如果要自行添加分支，请使用 gh stack add BRANCH-NAME-NEXT。
• 如果层开始增长太大，请考虑它是否偏离了计划，或者你实际上需要两个层而不是一个层。
• 在进行时为每个层创建新分支，因此每个分支都保持一个干净的独立差异。
• 准备好创建拉取请求时，请提交 Copilot 堆栈，或者如果要自行执行此操作，请使用 gh stack submit。
• 让每个拉取请求单独站出来。 重点标题和对层的简洁、有意义的描述通常足够。

示例提示

• Add the next layer in a new branch on top: the CRUD endpoints that use the user model from the branch below.
• This branch is getting large. Suggest how it could be split into two independently reviewable layers.

4. 在请求评审之前自行查看拉取请求

每个层都很小，使自我审查也更容易。 在涉及队友之前，对每个分支执行传递。 审阅者应收到你已信任的更改。

• 在每个分支上运行测试、linters 和代码扫描。 在请求评审之前，请 Copilot 帮助你根据标准检查每个层。
• 有关全面查看 AI 生成的更改的技术，请参阅 查看 AI 生成的代码。

5. 从底部开始请求堆栈评审

生成层后，审阅者会获得较小的差异，而不是大墙代码。

• 如果依赖项已强集成，请要求从堆栈底部开始的评审，以便可以在后续评审之前将更改集成到堆栈上。
• 如果需要不同层的单独人员进行评审，审阅者可以并行工作。 一个人可以查看数据模型，而另一个人则查看终结点，并且两者都没有通过整个功能进行浏览。

6. 循环访问反馈

单独查看反馈位于层上，而不是整个功能。 堆栈允许你就地修复正确的层，并将更改向上传递。

• 要求 Copilot 修改标记为审阅者的层。 代理将移动到正确的分支，进行更改，并将其提交到该分支。 然后，它会重新定基上述层，以便他们拾取修补程序。
• 将每个修补程序保留在它所属的层中。 错误分支上所做的更改可能会混淆并创建错误。
• 进行修复时，要求 Copilot 重新设置上述分支的基，并传播更改。
• 如果要自行在堆栈中移动，请导航分支 gh stack down， gh stack up或者 gh stack checkout BRANCH-NAME。 然后，提交更改并运行 gh stack rebase --upstack 以将更改抬上堆栈。

示例提示

• A reviewer flagged that the auth service doesn't handle expired tokens. Fix that on BRANCH-NAME and test the changes.
• I've rebased the layers above onto this fix. Check that the branch with endpoints still works with the change and flag anything that needs updating.

7. 从底层合并

堆栈按顺序合并，从指向主分支的层开始。 一次性合并层或逐个合并层，GitHub自动将下一层重新定位到主层。

• 一次从下到上合并堆栈，或者从堆栈中的任意位置合并堆栈，合并请求下方的所有分支都将从下到上合并。
• 每个层的差异与其父级完全相同，只有基本更改，因此一次可以轻松合并层，而不会影响正在进行的工作或评审。
• 使用自动合并或合并队列，以便每个层在批准后立即合并，并且其检查通过。 无需一次性等待整个堆栈。

一旦顶层合并，整个特征就已落地。 每一件都更有效地审查为一个小的故意更改，而不是一个大型拉取请求。

延伸阅读

• 查看 AI 生成的代码
• Managing stacked pull requests