📌 项目地址：github/gh-stack | ⭐ 756 颗星 | 🔧 Go | 📜 未标注
这个项目解决了什么问题
大型功能分支的 PR 往往包含大量改动，评审者面对几百个文件 diff 无从下手，要么拖延评审，要么草草扫一眼。gh-stack 把一个大分支拆成一串彼此叠加的小分支，每个分支只包含一个逻辑层级的改动，并生成有依赖关系的 PR 链。评审者按依赖顺序逐层查看，每一层的 diff 都足够小，评审效率显著提高。
这个项目是 GitHub 官方的 CLI 扩展，用 Go 编写，目前 756 stars。它的定位是自动化处理栈式分支的创建、rebase、PR 基础分支设置和栈内导航，让开发者不必手工管理层间依赖。
核心命令与工作流
安装基于 GitHub CLI，要求 gh v2.0+：
gh extension install github/gh-stack
基本使用流程分四步：
# 1. 初始化一个新栈，创建并切换到第一个分支
gh stack init
# 2. 在第一个分支上做提交后，在旁边增加一个新层
gh stack add api-endpoints
# 3. 一次性推送所有分支到远端
gh stack push
# 4. 为每一层创建 PR，并自动设置 base 为栈中下一层分支
gh stack submit
查看整体结构用 gh stack view，能同时展示分支层级和 PR 对应关系。
初始化也可以用非交互模式，直接指定分支名，已有分支会被自动采纳，缺失的会创建：
gh stack init feature-auth feature-api feature-frontend
默认 trunk 是仓库的默认分支，也可以通过 -b 或 --base 覆盖：
gh stack init -b develop feature-auth
工作原理
栈的模型是一张有序列表，紧贴 trunk 的是 bottom，最远端的是 top：
frontend → PR #3 (base: api-endpoints) ← top
api-endpoints → PR #2 (base: auth-layer)
auth-layer → PR #1 (base: main) ← bottom
─────────────
main (trunk)
gh stack submit 会为每个分支创建一个 PR，并把 PR 的 base 指向栈中它的下一层分支。这样每个 PR 的 diff 只包含该层自身的改动，评审者不会被层间重复代码干扰。
元数据存在仓库本地 .git/gh-stack 目录下（JSON 文件），不提交到版本库，不会污染仓库。rebase 中断时的状态独立存放在 .git/gh-stack-rebase-state。工具还会自动开启 git rerere，让冲突解决方案在多次 rebase 之间被记住，减少重复解决同一冲突的负担。
与手动 git 操作和其他方案的区别
手工实现栈式工作流需要自己记住每一层分支的父分支、每次 rebase 后手动修正各 PR 的 base，操作琐碎且容易出错。gh-stack 把元数据固化在本地区域，让分支管理命令化。
相比 Graphite 这类商业栈式 PR 工具，gh-stack 的优势在于它是 GitHub 官方维护的 CLI 扩展，直接集成在 gh 生态里，无需额外安装 GUI 或付费订阅，也不存在把代码托管到第三方服务的顾虑——所有数据留在自己的仓库里。
值得注意的几点
- 元数据存本地意味着换机器或重克隆仓库后需要重新初始化栈信息，不能指望远端自动恢复。
- 要求 gh CLI v2.0+，需要确认本机环境满足版本要求。
- stack 的分支名和层级关系是本地状态，多人协作时团队需要约定统一的 trunk 分支和命名规则，避免各自为政。
- 项目处于早期阶段（756 stars 但功能已可用），rebase 过程中的复杂冲突场景可能还打磨得不够完善，使用前建议在测试仓库演练几次。
对于经常处理大型功能拆分的团队，这个扩展值得一试。装上后跑一遍 init + add + push + submit，就能直观感受到它对流程的简化效果。