{"meta":{"title":"拉取请求中堆栈 AI 生成的代码","intro":"创建一个可快速查看的小型依赖拉取请求的堆栈。","product":"GitHub Copilot","breadcrumbs":[{"href":"/zh/enterprise-cloud@latest/copilot","title":"GitHub Copilot"},{"href":"/zh/enterprise-cloud@latest/copilot/tutorials","title":"教程"},{"href":"/zh/enterprise-cloud@latest/copilot/tutorials/stack-ai-generated-code-in-pull-requests","title":"Stack AI 拉取请求"}],"documentType":"article"},"body":"# 拉取请求中堆栈 AI 生成的代码\n\n创建一个可快速查看的小型依赖拉取请求的堆栈。\n\n> \\[!NOTE]\n> 堆积拉取请求处于 公开预览 其中且可能会更改。\n\n大型拉取请求难以查看和创建瓶颈，尤其是在 AI 帮助短时间内生成大量代码时。 随着拉取请求大小的增加，评审质量也会下降。 审阅者可能会忽略结果、错过问题或拖延并退出拉取请求，直到拉取请求变得过时并发展合并冲突。\n\n堆积拉取请求使大型代码更改可查看。\n\n堆栈是同一存储库中的一系列拉取请求，每个拉取请求都面向其下方的拉取请求的分支，形成位于单个分支（通常是主分支）上的有序链。 获取一组较小的拉取请求，而不是一个大型拉取请求。 由于每个拉取请求都有自己的重点差异，因此团队成员可以独立评审和批准每个层。\n\n本教程逐步讲解如何将堆叠拉取请求与代理配合使用，以在可单独审阅的层中生成功能。 对于我们的示例，我们将考虑如何将用户身份验证添加到应用。 我们将使用 GitHub Copilot CLI 和 `gh-stack` 代理技能。\n\n## 先决条件\n\n若要将 `gh-stack` 技能用于代理，首先需要安装和 GitHub CLI`gh-stack` CLI 扩展。 需要具备以下条件：\n\n* GitHub CLI （`gh`） 2.90.0 或更高版本，以及 Git 2.20 或更高版本。\n  * 使用 GitHub CLI. 进行身份验证`gh auth login`。\n* 可以推送到的 GitHub 存储库。\n* GitHub Copilot CLI 已安装并登录。\n\n在 GitHub CLI中 `gh-stack` ，安装扩展和技能。\n\n```shell\ngh extension install github/gh-stack\ngh skill install github/gh-stack\n```\n\n> \\[!NOTE]\n> 在本教程中，如果你希望自己运行堆栈命令，而不是允许 Copilot 这样做，则需要使用 GitHub CLI。\n\n## 1.在生成代码之前设计堆栈\n\n一个好的堆栈就像建房子，从坚实的基础开始，框架墙壁，安装电线，然后完成干墙。 构建的每个层都取决于下面的层。 最后，审阅者应该能够从底部到顶部读取拉取请求，并遵循功能走到一起。\n\n* 将特征拆分为层。 每个层应该是一个一致的更改，可以自行审查。\n  * 保持每个层足够小，使其拉取请求是快速读取的。 如果层感觉它需要一个较长的描述来审查，它可能太大。\n  * 自行决定边界，或处理 Copilot 计划。 无论哪种方式，你都拥有堆栈的形状。\n* 按依赖项对层进行排序。 基础更改位于底部。 依赖于它们的任何内容都会更高。 对于身份验证，可能是：\n  * 第 1 层：数据模型和迁移\n  * 第 2 层：CRUD 终结点\n  * 第 3 层：JWT 中间件和防护\n  * 第 4 层：集成和单元测试\n\n### 示例提示\n\n* `Propose a layered approach to add user authentication to this app. Order the layers by dependency, keeping each layer independently reviewable.`\n* `Review my planned layers and flag any that are too large or that depend on a branch above them.`\n\n## 2. 首先生成底层\n\n使用基础启动堆栈。 上述所有内容都取决于正确获取此层。\n\n* 通知 Copilot 你将生成堆积拉取请求，并要求它基于计划生成第一层。 代理使用 `gh-stack` 技能创建堆栈的第一个分支。\n* 如果希望自己创建堆栈，请使用前缀直接 `gh stack init`创建堆栈，以保持分支名称整洁，例如 `gh stack init BRANCH-NAME-1`。\n* 在继续操作之前，请查看生成的更改。 底层的错误传播到其上方的每一个分支，因此请在继续操作之前进行评审。\n\n### 示例提示\n\n* `Start the pr-stack and build only the first layer: the user data model and migration.`\n* `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.`\n\n## 3.将每个新代码层堆叠在顶部\n\n建立基础后，一次生成一层特征的其余部分。\n\n* 要求 Copilot 添加下一层并在下面的层上下文中实现它。 代理会将分支添加到堆栈顶部，并在其中提交工作。\n* 如果要自行添加分支，请使用 `gh stack add BRANCH-NAME-NEXT`。\n* 如果层开始增长太大，请考虑它是否偏离了计划，或者你实际上需要两个层而不是一个层。\n* 在进行时为每个层创建新分支，因此每个分支都保持一个干净的独立差异。\n* 准备好创建拉取请求时，请提交 Copilot 堆栈，或者如果要自行执行此操作，请使用 `gh stack submit`。\n* 让每个拉取请求单独站出来。 重点标题和对层的简洁、有意义的描述通常足够。\n\n### 示例提示\n\n* `Add the next layer in a new branch on top: the CRUD endpoints that use the user model from the branch below.`\n* `This branch is getting large. Suggest how it could be split into two independently reviewable layers.`\n\n## 4. 在请求评审之前自行查看拉取请求\n\n每个层都很小，使自我审查也更容易。 在涉及队友之前，对每个分支执行传递。 审阅者应收到你已信任的更改。\n\n* 在每个分支上运行测试、linters 和代码扫描。 在请求评审之前，请 Copilot 帮助你根据标准检查每个层。\n* 有关全面查看 AI 生成的更改的技术，请参阅 [查看 AI 生成的代码](/zh/enterprise-cloud@latest/copilot/tutorials/review-ai-generated-code)。\n\n## 5. 从底部开始请求堆栈评审\n\n生成层后，审阅者会获得较小的差异，而不是大墙代码。\n\n* 如果依赖项已强集成，请要求从堆栈底部开始的评审，以便可以在后续评审之前将更改集成到堆栈上。\n* 如果需要不同层的单独人员进行评审，审阅者可以并行工作。 一个人可以查看数据模型，而另一个人则查看终结点，并且两者都没有通过整个功能进行浏览。\n\n## 6. 循环访问反馈\n\n单独查看反馈位于层上，而不是整个功能。 堆栈允许你就地修复正确的层，并将更改向上传递。\n\n* 要求 Copilot 修改标记为审阅者的层。 代理将移动到正确的分支，进行更改，并将其提交到该分支。 然后，它会重新定基上述层，以便他们拾取修补程序。\n* 将每个修补程序保留在它所属的层中。 错误分支上所做的更改可能会混淆并创建错误。\n* 进行修复时，要求 Copilot 重新设置上述分支的基，并传播更改。\n* 如果要自行在堆栈中移动，请导航分支 `gh stack down`， `gh stack up`或者 `gh stack checkout BRANCH-NAME`。 然后，提交更改并运行 `gh stack rebase --upstack` 以将更改抬上堆栈。\n\n### 示例提示\n\n* `A reviewer flagged that the auth service doesn't handle expired tokens. Fix that on BRANCH-NAME and test the changes.`\n* `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.`\n\n## 7. 从底层合并\n\n堆栈按顺序合并，从指向主分支的层开始。 一次性合并层或逐个合并层，GitHub自动将下一层重新定位到主层。\n\n* 一次从下到上合并堆栈，或者从堆栈中的任意位置合并堆栈，合并请求下方的所有分支都将从下到上合并。\n* 每个层的差异与其父级完全相同，只有基本更改，因此一次可以轻松合并层，而不会影响正在进行的工作或评审。\n* 使用自动合并或合并队列，以便每个层在批准后立即合并，并且其检查通过。 无需一次性等待整个堆栈。\n\n一旦顶层合并，整个特征就已落地。 每一件都更有效地审查为一个小的故意更改，而不是一个大型拉取请求。\n\n## 延伸阅读\n\n* [查看 AI 生成的代码](/zh/enterprise-cloud@latest/copilot/tutorials/review-ai-generated-code)\n* [管理堆积拉取请求](/zh/enterprise-cloud@latest/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests)"}