github/gh-stack

如果你所在的团队习惯把大改动拆成一串小 PR 来审查，在动手自己写脚本管理 Git 分支之前，值得先看看 gh stack。它是一个 GitHub CLI 扩展，把"栈"这件事正式化：分支顺序记录在本地，按顺序变基、推送，再生成互相链接的 PR，每个 PR 的目标分支永远是它下面那一层。

解决什么问题

开发者提交一个大改动时，希望审查者按层次看，而不是面对一个上千行的 diff。今天这意味着一层层手动建分支、记住顺序、逐个设置 PR 的目标分支，底层一改还要整条链变基。真正的摩擦是这些琐碎记录，不是代码本身。gh stack 接管了这部分记录：按顺序添加分支，提交一次，每一层就变成一个目标为下一层的 PR，审查者只看到自己那层的 diff。

有什么不同

有意思的机制是栈元数据。它存在 Git 公共目录下的 JSON 清单里（普通克隆中即 <common-dir>/gh-stack），而不是仓库里，所以提交之前"栈"只是一个本地概念。由于该清单在 linked worktree 之间共享，不同的栈、或同一个栈的不同分支可以分布在不同 worktree 中，rebase 和 sync 会自动更新每个受影响分支所属的干净 worktree。脏的、正忙的、缺失的或已变更的属主会中止操作，无关的 worktree 不受影响。

代价是，工具接管了一类 Git 本身不管理状态。rebase 和 modify 的恢复日志与清单放在一起，而 Git 自己的 HEAD、index 和 rebase 标记仍然按 worktree 分开。提交时还会在 GitHub 上创建 "Stack" 分组，因此这套流程默认审查者和仓库设置能配合这种结构。官方扩展是非固定版本安装，会在后台检查最新的 latest release，成功结果缓存 24 小时，每天最多在 stderr 追加一次升级提示；stdout 和 JSON 输出不变。想要及时拿到新版本时这很方便，但对非交互脚本来说又多了一个变量。

谁值得试

适合：已经在把功能拆成相互依赖分支的开发者或小团队，尤其是使用 worktree 的人，希望提交后的 PR 正确表达依赖关系，并希望整条链一起变基。worktree 感知的更新行为是它相对临时脚本最有力的理由。不适合：改动一个 PR 就装得下的独立开发者，或者审查流程并不围绕链式分支组织的团队，额外的分支记录换不来什么。使用其他代码托管平台的团队也用不上，因为提交目标是 GitHub PR。

文档还提供了给 AI 编程助手用的路径：安装 gh-stack skill 可以让编程 Agent 了解 stacked PR 和该 CLI 的用法（README）。这是可选项，不是使用扩展的前提。

使用条件与边界

需要 GitHub CLI gh v2.0+、Git 2.36+，以及已认证的 GitHub 仓库（安装说明）。Git 版本下限重要，因为 worktree 处理是栈分发与更新的核心；更老的 Git 没有文档说明支持。本地元数据放在公共目录而非仓库里，所以全新克隆或换一台机器不会带上栈定义——迁移时要准备重建或重新收编分支。

日常维护：改变历史的操作（rebase、sync）依赖属主 worktree 干净且可用，长期存在的栈需要对"哪个 worktree 放哪个分支"有纪律。栈不提交，队友在 PR 提交前看不到栈结构，PR 分组也在 GitHub 一侧生成。

HotRepo 点评

HotRepo 的记录显示，2026-08-01 为 730 星、2026-08-02 为 890 星、2026-10-28 为 1,724 星，共有 3 个日榜记录日（项目）。覆盖太稀疏，无法判断这种关注是否持续。采用前先确认一件具体的事：你的审查者和仓库合并设置是否真的能配合该工具创建的 stacked PR 分组，决定这套流程是否划算的是这个模型，而不是 CLI 本身。