这个真的必要吗？认识一下 gh stack
来源：dev.to — 2026-09-03
📋 概述
作者被领导长期要求「把 diff 变小」，AI 辅助写码让 PR 体积膨胀成为常见瓶颈。GitHub 的官方扩展 gh stack 把「叠 PR」从需要手工逐条 rebase + force-push 的痛苦事，变成几个命令自动管理的事：每个 PR 是一张煎饼，目标指向它下面那一层，GitHub 负责层与层之间的「糖浆」（依赖关系的自动传播）。作者的比喻贯穿全文，尤其推荐了末尾给 AI 的 agent 设置。
🔑 核心要点
- 大 PR 难以评审并制造瓶颈——GitHub 文档直言尤其当 AI 帮你在短时间内生成大量代码时；`gh stack` 让分支保持小 diff 仍能在一次 merge 里一起发布
- 工作流：`gh stack init` 建分支、`gh stack add` 在当前位置上加下一层、`gh stack submit` 一次性推送并打开所有关联 PR；`sync` 只推刷新已有 PR、没有建链能力，不 submit 就始终没有东西上 GitHub
- 在底层改了提交后只需在那一层 commit 再 `gh stack sync`，它会一次 rebase 全部父链并推送，免去逐分支 force-push；两层改到同一行则停在冲突并把所有分支还原到原状
- 导航命令全：`gh stack view` 用箭头上下、`↵` 检出当前层、`o` 浏览器开 PR、`c`/`f` 看该层提交与文件；还有 bottom/top/down/up/trunk 的快捷跳
- 去掉一层用 `gh stack unstack` 拆掉 GitHub 上的链，再 `gh stack init` 从保留下来的分支重建并 submit 重新指基——分支、提交、PR 全部幸存，只丢掉它们之间的链条
- 合并铁律：无论站在哪一层，都会把从那一层到 trunk 的全部一起合并；配合「每个 PR 是一张指向下层煎饼」的模型，整个多分支工作流变得直观
💡 金句
大 diff 难以评审；当 AI 在短时间里生成海量代码时，它尤其会成为瓶颈。
👍 0
👎 0
← 返回 dev.to 首页