Stackit - 用轻量 CLI 管理 stacked PR 工作流
很多团队都知道“小 PR 更容易 review”，但真正实践起来并不轻松。一个功能被拆成三四个分支后，父子分支关系、rebase 顺序、PR base、已经合并的下层分支、临时修补应该 amend 到哪一层，都会变成额外的脑内状态。Graphite 这类工具已经证明了 stacked changes 的价值，但不是每个团队都想把整个提交流程搬到一个更重的平台上。
今天推荐的 getstackit/stackit 是一个更贴近本地 Git 的选择。它是 Go 写的 CLI，目标是管理 stacked changes：用小分支组成一棵 stack tree，自动跟踪 parent / child 关系，帮助你 restack、提交整组 PR、合并、清理和检查分支状态。
发布时 GitHub 页面显示项目约 31 stars、1 fork，主要语言是 Go，许可为 MIT。仓库创建于 2025-12-14，最近仍在高频更新；release 页面显示最新版本为 v0.19.1，发布于 2026-06-13。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | getstackit/stackit |
| 定位 | Git stacked changes / stacked PR CLI |
| Stars | 约 31 |
| Forks | 1 |
| 主要语言 | Go |
| 许可 | MIT |
| 最新版本 | v0.19.1 |
它把 stack 当作一棵分支树
Stackit 的 README 用 stacked diffs 来解释自己的工作模型：一个大功能可以拆成多个小分支，每个分支对应一个聚焦的 PR。最简单的情况是一条线：API 变更、实现、UI、测试依次叠上去；复杂一点时，某个中间分支也可以分出多个子分支。
这和普通的“开几个 feature branch”不同。stacked workflow 的难点不是创建分支，而是持续维护关系：当前分支的 parent 是谁，哪些 child 需要跟着 rebase，哪个 PR 应该指向哪个 base，底层 PR 合并后上层分支怎么同步。Stackit 把这些关系显式化，stackit log 可以展示当前 stack tree，parent / children 可以检查当前分支位置。
对经常拆大需求的人来说，这个可视化和元数据层很关键。它减少的不是 Git 命令本身，而是分支状态在脑子里漂移的成本。
核心命令覆盖创建、同步和提交
README 的 getting started 很直接：
stackit init
stackit create add-api -m "feat: add base api"
stackit create add-logic -m "feat: implement logic"
stackit log
stackit submitstackit init 会识别 trunk branch，并为仓库准备 stack 元数据。stackit create 在当前分支上创建新分支，stackit log 展示树形结构，stackit submit 则把整组分支推到 GitHub 并创建或更新 PR，同时让上层 PR 指向正确的下层分支。
它还覆盖了长期维护 stack 时更容易出错的部分：
restack：当 parent 变了，把 child 分支重新接上。sync：和 trunk 同步，并清理已经合并的分支。merge：按 stack 顺序合并，或把 stack 收拢成一个原子 PR。absorb：把当前改动吸收到 stack 中合适的 commit。lock/freeze：阻止关键分支被误改。
这些能力组合起来，像是在 Git 之上补了一层“变更序列管理”。它没有替代 Git，而是把多分支协作里最容易忘的关系记录下来。
v0.19.1 的重点是 submit 和 get 性能
最新 release v0.19.1 的更新说明很适合判断项目是否还在认真打磨。这个版本的重点不是新增噱头，而是减少 submit 和 get 路径里的 N+1 调用。
release notes 提到，submit 现在会把整组 stack 用一次 git push 推送，PR 信息通过一次 GraphQL 查询获取，并批量处理 remote ref、PR content 和 empty-branch validation。get 也从已获取的元数据推导 parent，避免串行爬 GitHub。
这说明 Stackit 已经碰到了真实 stacked workflow 的性能痛点。小 demo 里只有两三个分支时，逐个查询不是问题；当 stack 变大、PR 数量变多、CI 和 remote 状态都要同步时，批处理才会明显影响体验。
Agent 集成是一个有意思的侧面
Stackit 还提供 stackit agent install，可以生成 Claude Code、Codex 和 Cursor 相关的集成文件。README 列出的技能包括 stack-status、stack-create、stack-submit、stack-sync、stack-restack、stack-absorb、stack-fix 和 stack-describe。
这个设计很合理。Stacked PR 工作流本来就很适合 coding agent：agent 可以帮你读当前 stack state、整理 PR 描述、修某一层的测试、把修补吸收到正确 commit。但前提是 agent 必须理解 stack 的结构，否则它很容易在错误分支上修改、把 base 搞乱，或者生成无法 review 的混合变更。
把 stack 操作变成专门的 agent skill，比只在 AGENTS.md 里写几段约定更可靠。它给 agent 一个面向任务的入口，而不是让 agent 自己拼 Git 命令。
适合什么场景
Stackit 最适合已经感受到“大 PR 太重、小 PR 管理太烦”的团队或个人。典型场景包括：
- 一个功能天然能拆成 API、实现、UI、测试、迁移等多个可 review 层。
- review 周期较长，但开发者不想等底层 PR 合并后才开始上层工作。
- 团队希望保留 GitHub PR review 流程，而不是迁移到全新的代码评审平台。
- 正在使用 Codex、Claude Code 或 Cursor，希望 agent 能理解分支 stack。
它不一定适合所有仓库。如果团队习惯短生命周期 feature branch、每天都能快速合并，stacked workflow 可能会显得多余。Stackit 的价值来自复杂变更和 review 延迟，一旦没有这些压力，额外的分支结构反而会增加流程感。
小结
getstackit/stackit 是一个早期但方向清楚的 Git 工具。它把 stacked changes 的核心关系落到本地 CLI：树形分支、自动 restack、整组 PR 提交、合并清理、分支保护、worktree 和 agent 集成。
如果你正在用 GitHub review 一个跨多层的大功能，又不想把所有内容塞进单个 PR，Stackit 值得关注。它解决的不是“怎么写代码”，而是“怎么让一组相关变更保持可 review、可同步、可交给 agent 操作”。