用途：把大型代码改动拆成同仓库内一串小的依赖式拉取请求（堆叠 PR）。栈底 PR 指向主干（通常默认分支），其上每个 PR 指向下方 PR 的分支，使各层可独立评审与合并。分层原则：基础性改动放低层（共享类型、数据库 schema、核心逻辑、配置），依赖它们的代码放高层（API 路由、UI 组件、端到端测试）；切换到不同关注点或当前分支已过大时新增一层。
主要能力：通过 gh stack 子命令完成初始化、加层、推送、创建并链接 PR、查看、导航、变基、同步、重构与合并。gh stack init 创建跟踪项与首个分支；gh stack add 在栈顶加分支；gh stack submit 推送分支、为每个分支创建指向正确 base 的 PR 并链接成栈；gh stack rebase 从主干向上级联变基；gh stack sync --prune 在底层 PR 合并后更新本地状态并清理已合并分支；gh stack merge 可自底向上合并至指定 PR。推送使用按分支的 --force-with-lease。
必要用法：需 GitHub CLI (gh) 2.90.0 及以上、Git 2.20 及以上并通过 gh auth login 认证，然后安装扩展：gh extension install github/gh-stack。从仓库根目录运行 gh stack init 初始化。非交互终端中 gh stack submit 相当于 --auto，新建 PR 默认是草稿，除非传 --open；检查状态用 gh stack view --short 或 --json，勿用会打开全屏界面的裸 gh stack view。gh stack modify 与 gh stack switch 仅交互式 TTY，代理不应驱动，可用 gh stack unstack 后 gh stack init 重建的非交互式流程替代。可用退出码判断问题（如 2 不在栈中、3 变基冲突、9 仓库未启用堆叠 PR）；遇到退出码 9 应向用户报告而非绕过。
适用场景：需要把大改动拆小便于逐层评审、多人并行、依赖清晰的工程流程。
限制：所有分支须在同一仓库，不支持跨 fork；不支持 GitHub Desktop；CI 检查与分支保护规则对栈中每个 PR 均生效；合并需自底向上且不能绕过合并要求；需签名提交的仓库应在本地用 gh stack rebase 而非网站按钮。资料未提供收费、价格与平台细节。