前言¶
大型功能改動往往意味着一個體積龐大的 Pull Request：審查者面對上千行 diff 容易走馬觀花，作者則要手動維護多條依賴分支、反覆 rebase，CI 與分支保護規則還常常只對棧底 PR 生效。Stacked Pull Requests（堆疊 PR）是業界長期探索的解法——把一次大變更拆成有序、有依賴關係的小 PR 鏈，逐層審查、按需合併。
2026 年 7 月 30 日，GitHub 在 Changelog 中宣佈 Stacked Pull Requests 進入公測（Public Preview），並在官網、CLI、移動端及 API 層面提供原生支持。配套開源擴展 github/gh-stack 與 Copilot 可用的 gh-stack skill 一併發佈。Next.js、TED、WHOOP 等團隊已在預覽期使用，Hacker News 與開發者社區討論熱度較高。本文基於官方 Changelog、文檔與 gh-stack 倉庫說明，梳理這一能力是什麼、解決什麼問題，以及如何上手。
什麼是堆疊 PR¶
堆疊 PR 指同一倉庫內兩個及以上相互依賴的 Pull Request，形成一條「自下而上」的分支鏈：
┌── feat/frontend → PR #3（base: feat/api-endpoints） ← 棧頂
┌── feat/api-endpoints → PR #2（base: feat/auth-layer）
┌── feat/auth-layer → PR #1（base: main） ← 棧底
main（默認主幹分支）
規則要點如下：
- 棧底 PR 的目標分支是主幹（通常是
main，也可以是 release 分支等任意 trunk）。 - 上一層 PR 的目標分支是下一層 PR 所在的分支，而非直接指向
main。 - 每個 PR 只展示「本層相對下一層」的 diff，審查者看到的是聚焦、可消化的小改動。
- 依賴順序：若 A 層代碼依賴 B 層，則 B 必須在同層或更低層；切換關注點（例如從後端切到前端、從核心邏輯切到測試）時，應新建一層分支。
官方文檔強調的核心原則：不必等底層 PR 合併後再開上層 PR，可以在底層仍 open 的狀態下繼續往上疊，從而在大項目推進中保持開發節奏。
爲何此時受到關注¶
堆疊 diff 並非新概念，Graphite、Sapling、git-branchless 等工具此前已在 GitHub 生態外提供類似工作流。GitHub 將其做成平臺原生能力，主要回應三類現實痛點：
1. 大型 PR 審查瓶頸¶
單個 PR 過大時，審查慢、易漏檢、易 stale 併產生合併衝突。Next.js 負責人 Tim Neutkens 在官方公告中稱，團隊使用堆疊 PR 數月，能在交付大功能的同時保持每層改動足夠小、便於 review。
2. AI 輔助開發帶來的新壓力¶
TED CTO Andy Merryman 提到，AI 顯著提升了開發產出，但 PR 體積隨之膨脹，審查成爲新瓶頸。堆疊 PR 把大 diff 拆成語義清晰的小塊，有助於提高審查速度與準確性。GitHub 文檔也明確寫到：當 Agent 連續完成多個有依賴的任務時，可直接映射爲「一層 PR 對應一個任務」的棧結構。
3. 手工維護依賴分支的成本¶
在沒有原生支持時，拆分依賴 PR 意味着：手動 rebase 同步、CI 可能只跑棧底、中間層 PR 脫離上下文難以審查。GitHub 堆疊 PR 將整條鏈視爲關聯單元，同時保留每層的小粒度 diff，並自動處理級聯 rebase 與 base 分支重定向。
平臺原生能力一覽¶
公測版本在以下入口可用（官方文檔覈實）：
| 入口 | 說明 |
|---|---|
| github.com | PR 頁頂顯示棧圖標與層數；合併框內有 stack map，可一鍵跳轉各層 |
| GitHub CLI | gh stack 擴展，管理本地分支、推送、提交 PR |
| GitHub Mobile | 移動端同樣支持棧視圖與操作 |
| Webhooks / REST / GraphQL | pull_request 事件含 stack 對象；REST 可列出、創建、擴展、解散棧 |
| Copilot 等 Agent | 通過 gh-stack skill 調用 CLI 工作流 |
當前限制（文檔明確標註）：
- 所有分支必須在同一倉庫，不支持跨 fork 堆棧。
- GitHub Desktop 暫不支持。
- 功能處於 Public Preview，接口與行爲可能調整。
- Merge Queue 對堆疊 PR 的支持將在未來數週內逐步 rollout，並非所有倉庫立即可用。
審查與合併機制¶
獨立審查、並行推進¶
打開棧中任意一層 PR，審查界面僅顯示該層 diff；頂部 stack map 展示整棧結構與各層狀態。不同審查者可同時 review 不同層，互不阻塞。
分支保護與 CI¶
合併要求以棧底 PR 的 base 分支（通常爲 main）爲準，但每一層都會執行分支保護規則（如 CODEOWNERS）以及針對默認分支觸發的 CI，而非只有棧底跑檢查。這解決了以往「中間層 PR 質量狀態不透明」的問題。
合併方式¶
合併必須自底向上，支持三種策略：
- 整棧合併：合併棧頂 PR，其下所有未合併層一併落地（merge commit、squash、rebase 均支持）。
- 部分合並：合併棧中某一中間層，該層及以下合併，上方層保持 open 並自動 rebase、重定向 base。
- 單層合併：只合並棧底或部分底層，按需逐步推進。
合併結果與逐層單獨合併的提交歷史一致。若通過 API 合併，需使用支持堆棧的新 merge API（文檔 API 版本 2026-03-10 起）。
自動 rebase¶
rebase 是堆棧工作流中最易出錯的環節。GitHub 支持在 PR 頁面觸發服務端級聯 rebase；本地則可用 gh stack 擴展執行級聯 rebase。合併棧底後，剩餘分支會自動 rebase，下一層 PR 的 base 會指向新的主幹位置。
用 gh-stack 快速上手¶
官方 CLI 擴展倉庫：https://github.com/github/gh-stack（截至寫作時 GitHub 上 star 數已逾數百）。要求已安裝 GitHub CLI（gh v2.0+）。
1. 安裝擴展與 Agent Skill¶
# 安裝 gh stack CLI 擴展
gh extension install github/gh-stack
# 可選：爲 Copilot 等 Agent 安裝 gh-stack skill
gh skill install github/gh-stack
2. 創建第一個棧¶
典型工作流如下：
# 初始化棧（創建並 checkout 第一層分支）
gh stack init
# 在第一層上完成 commit ...
# 在棧頂再疊一層
gh stack add api-endpoints
# 繼續 commit，按需 gh stack add ...
# 推送所有分支
gh stack push
# 查看棧結構
gh stack view
# 爲各層創建並關聯 PR
gh stack submit
也可非交互式指定分支名：
gh stack init feature-auth feature-api feature-ui
棧元數據保存在本地 .git/gh-stack（JSON，不提交到倉庫），用於跟蹤分支順序；gh stack init 會自動啓用 git rerere，以便 rebase 衝突解決可被記住。
3. 常用導航命令¶
gh stack 中 up 指向遠離 trunk 的方向（棧頂），down 指向靠近 trunk 的方向。其他命令包括 checkout、sync（拉取 trunk 並級聯 rebase）、restack（變基整棧）等，完整說明見倉庫 README。
與 Merge Queue、Copilot 的關係¶
Merge Queue：GitHub 公告寫明，堆疊 PR 的 Merge Queue 支持正在分階段推出。John Resig 在公告中提及，可將 5 個堆疊 PR 一次性送入 merge queue 合併——這依賴該能力在目標倉庫已啓用。
Copilot Agent：通過 gh-stack skill，Agent 可遵循與 CLI 相同的分支順序創建棧、提交 PR，避免把多個無關聯任務塞進單一巨大 diff。這與 GitHub 文檔中「Agent 完成一個任務後基於其繼續下一任務」的描述一致。
公測 rollout 與反饋渠道¶
根據 2026-07-30 官方 Changelog：
- 堆疊 PR 公測將在未來數天內向所有倉庫逐步開放。
- Merge Queue 集成將在未來數週內逐步推出。
- 詳細用法見文檔：About stacked pull requests；反饋可在 GitHub 的 stacks discussion 中提交。
小結：值不值得現在試¶
若你或團隊經常面對「一個大 PR 沒人敢審」或「AI 產出快、審查跟不上」的情況，GitHub 原生堆疊 PR 值得在公測期試點：工作流與現有 review、checks、分支保護兼容，CLI 與 Agent skill 降低了建棧成本。若團隊已深度依賴 Graphite 等第三方工具，可先並行對比再決定是否遷移；跨 fork 協作、Desktop 用戶則需等待後續支持或繼續沿用現有方案。
無論如何，把大變更拆成有依賴順序的小 PR、逐層審查、整棧一鍵合併——這條思路已被 GitHub 寫入平臺默認能力，值得納入下一次大型改動的分支策略考量。
