Skip to main content
当任务过大，难以通过单个 PR 轻松审查时，Devin 可以将其拆分为一个堆栈：一系列有序的拉取请求，共同构成一项工作，并按自底向上的顺序依次合并。堆栈中的每个 PR 都是常规且聚焦的 PR，建立在其下方的 PR 之上——审查者每次只需查看一个小型、自包含的变更，而非一个庞大的 diff。 Devin 的堆栈基于 GitHub 原生的堆叠拉取请求，因此堆栈是 GitHub 的一等对象，而非依靠分支命名约定维系的形式。
堆叠 PR 仅支持 GitHub.com 代码仓库。GitHub Enterprise Server、GitLab 和其他提供商不提供堆叠 PR API。

​
堆栈 的工作原理

堆栈 是一系列补丁：
  • PR 按从下到上的顺序排列。最底层的 PR 以你的主干分支 (例如 main) 为目标分支；其余每个 PR 的基分支都是其下方 PR 的头分支。
  • 由于每个 PR 都与其下方的层进行 diff，因此只会显示自身的变更，不会混入上层或下层的内容。
  • 堆栈 按从下到上的顺序合并。合并堆栈 中的一个 PR 时，会以原子方式在一次操作中合并其下方所有 Open PR。随着较低层的 PR 被合并，GitHub 会自动将其余 PR 的目标分支重新定向为主干分支。

​
Devin 创建堆栈 的时机

Devin 会有意地创建堆栈，而不是随意将 PR 叠加在一起。只有当它刻意将一项工作拆分为一系列需要按顺序合并的 PR 时，才会创建堆栈——例如，先修改架构，再实现使用该架构的服务层，最后构建其上的 UI。仅仅因为基于另一个 PR 的分支创建的 PR，不会被归入同一个堆栈。 当 Devin 规划堆栈时，会：
  1. 在创建任何 PR 之前，公布堆栈 的名称，以便你能在会话中看到这一系列工作逐步成形。
  2. 将每个 PR 都创建为常规且聚焦的 PR——各自拥有独立的描述和 CI，并以其下方 PR 的头分支作为目标分支。
  3. 在 PR 创建完成后，在 GitHub 上将这些 PR 归组为一个堆栈。
每一层都遵循与 Devin 提交的任何独立 PR 相同的标准：精简且聚焦的 diff，以及为未看过代码的审查者撰写的高信息量描述。

​
保持堆栈同步

堆栈创建后并非固定不变。在整个会话期间，Devin 会持续关联堆栈中的每个 PR：
  • 冲突解决 — 如果任何一层与其下方的分支发生合并冲突 (例如，较低层合入审查反馈后，或主干在堆栈下方发生变动) ，Devin 会自动收到通知并静默解决冲突。只有当冲突涉及需要你决定的实质性问题时，它才会询问你。
  • 整个堆栈的 CI — Devin 会监控每一层的 CI，并在出现失败时进行修复，跟踪整个系列的就绪状态，而不是逐个盯着 PR。
  • 自动重新定向 — 随着堆栈底部的 PR 被合并，GitHub 会将其余 PR 重新定向到主干。无需手动管理变基操作。

​
使用堆栈 PR

你可以在会话中指定 Devin 的 PR 堆栈方式：
  • 要求 Devin 将大型改动拆分为一组堆栈 PR，或将工作保留为单个 PR。
  • 要求 Devin 将后续 PR 添加到现有堆栈的顶部。
  • 要求 Devin 检查堆栈的状态——它会报告每一层的状态、CI、审查结论和可合并性。
  • 要求 Devin 取消堆栈——堆栈将被拆除，其中尚未合并的 PR 会重新成为独立 PR，分支保持不变。已合并的层仍保持合并状态。
在会话视图中，属于某个堆栈的 PR 会显示其所属堆栈；已发布的堆栈会在其 PR 创建前显示，以便你可以跟踪 Devin 如何构建这一系列 PR。

​
审查和合并堆叠 PR

Devin Review 将堆叠 PR 作为一等功能：整个系列及各层的就绪状态一目了然，并可通过原子化的自底向上堆栈合并来合并整个堆栈。详情请参阅 Devin Review 文档中的“堆叠 PR”部分。

​
限制

  • 仅支持 GitHub.com — GitHub Enterprise Server、GitLab、Bitbucket 和 Azure DevOps 均不支持堆栈。
  • 堆栈大小 — 每个堆栈包含 2 至 100 个 PR。
  • 合并 — 堆叠 PR 无法通过 GitHub 的常规合并流程合并；必须通过堆栈合并，将所选 PR 及其下方所有处于 Open 状态的 PR 一并合并。