前言¶
大型功能一次改完、開一個巨型 Pull Request，是不少團隊都踩過的坑：Reviewer 對着幾千行 diff 望而卻步，CI 跑一輪就要半天，中間任何一層被 block，整條分支鏈都要手動 rebase。Stacked Pull Requests（堆疊 PR）的思路並不新——把大改動拆成一串有依賴關係、各自可審查的小 PR——但過去多半要靠 Graphite、Sapling 等第三方工具，或者自己維護分支基線。
2026 年 7 月 30 日，GitHub 在 Changelog 中宣佈 Stacked Pull Requests 進入 Public Preview（公測），並配套開源 CLI 擴展 github/gh-stack。堆疊 PR 不再是「插件生態裏的高級玩法」，而是寫進 GitHub 原生 PR 流程的能力：Stack Map UI、一鍵合併整棧、與 Branch Protection / Merge Queue 聯動，都可以在官方文檔裏查到。本文基於 GitHub 官方 Changelog、文檔與 gh-stack 倉庫 README，梳理這項功能解決什麼問題、怎麼用，以及和 Trunk-based Development 的關係。
堆疊 PR 是什麼¶
官方定義裏，Stack（棧） 是同一倉庫內一系列 Pull Request 的有序鏈：最底層 PR 以 trunk（通常是 main）爲 base，上一層 PR 以下一層分支爲 base，依此類推。Reviewer 打開任意一層，看到的 diff 只包含該層的改動，而不是整坨功能的全部文件。
一個典型的三層棧結構如下：
frontend → PR #3（base: api-endpoints）← 棧頂
api-endpoints → PR #2（base: auth-layer）
auth-layer → PR #1（base: main） ← 棧底
─────────────
main（trunk）
這與 Trunk-based Development 並不衝突：trunk 仍是最終合入目標，堆疊 PR 只是把「從 trunk 到最終功能」的路徑拆成若干可獨立審查的增量層。Next.js 負責人 Tim Neutkens 在 GitHub 公告中也提到，Vercel 團隊用堆疊 PR 在保持大功能交付節奏的同時，把單次 Review 粒度壓小。
需要提前知道的限制（均來自官方文檔）：
- 所有分支必須在同一倉庫，不支持跨 fork 堆棧。
- GitHub Desktop 暫不支持堆疊 PR。
- 合併前棧內分支之間必須保持完全線性歷史；trunk 前進或底層分支有新提交時，需要 cascading rebase 恢復。
2026 年 7 月公測帶來了什麼¶
GitHub 此次公測的核心變化，是把堆疊 PR 從「CLI 輔助 + 網頁手動關聯」升級爲平臺一等公民：
- Stack Map：PR 頁面頂部展示棧結構，Reviewer 可並行審查不同層，互不阻塞。
- Branch Protection 按棧底評估：無論某層 PR 的 direct base 是哪條分支，Required Reviews、Status Checks、CODEOWNERS、Code Scanning 都按棧的 trunk 來跑。GitHub Actions 的
pull_request事件也會按棧底分支觸發，無需改 workflow。 - 一鍵合併：合併棧頂（或任意已就緒層）時，其下方所有未合併層可原子性一併合入；若只合並較低層，上方 PR 會自動 rebase 並 retarget。
- Merge Queue 支持：整棧可按正確順序入隊；若某層被移出隊列，其上所有層也會一併移除。Merge Queue 的 merge group 最大容量允許超出配置上限最多 50%，以儘量保持整棧同批合併。
- 三種合併方式均可用：Merge Commit、Squash、Rebase，整組 PR 作爲一次原子操作落地。
公測 rollout 節奏：未來數天內向所有倉庫逐步開放；Merge Queue 對堆疊 PR 的支持將在未來數週內分批上線。
安裝 gh stack CLI¶
本地開發工作流推薦安裝官方 CLI 擴展。前置條件是 GitHub CLI v2.0 及以上。
gh extension install github/gh-stack
github/gh-stack 採用 MIT 協議，倉庫創建於 2026 年 2 月，截至公測公告前後已在 GitHub 上獲得數百 Star。棧的元數據保存在本地 .git/gh-stack（JSON，不會提交到倉庫）；gh stack init 會自動啓用 git rerere，重複 rebase 時儘量複用已解決的衝突。
若使用 GitHub Copilot 等 AI Agent，還可安裝配套 skill，讓 Agent 熟悉堆疊 PR 工作流：
gh skill install github/gh-stack
不裝 CLI 也可以：底層 Git 操作是標準流程，可直接在 github.com 或 GitHub 移動 App 上創建堆棧；Jujutsu、Sapling 等工具推送分支後，同樣可用 gh stack 或網頁端開棧。
快速上手：從 init 到 submit¶
下面是一個最小可用流程，命令來自 gh-stack 官方 README。
1. 初始化棧並添加層¶
# 交互式創建棧的第一層分支
gh stack init
# 在當前層之上繼續疊加
gh stack add api-endpoints
# 再疊一層
gh stack add frontend
也可一次性指定多個分支，或指定非 main 的 trunk：
gh stack init --base develop feature-auth feature-api feature-ui
gh stack add 支持 -m 提交信息、-A / -u 暫存改動後再建分支，適合「改完一層立刻開下一層」的節奏。
2. 推送並創建關聯 PR¶
gh stack push
gh stack view
gh stack submit
gh stack submit 會爲棧內每個分支創建 PR，base 自動設爲下一層分支，並在 GitHub 上建立 Stack 關聯。加 --auto 可跳過交互式編輯器，適合腳本化場景。
3. 底層改動後的同步¶
Reviewer 對棧底 PR 提出修改後，需要把變更 cascade 到上層：
gh stack rebase
gh stack push
網頁端也可在 Merge 區域點擊 Rebase stack，由服務端執行 cascading rebase。
gh stack sync 則用於同步遠程狀態、清理已合併分支等日常維護。
4. 合併¶
棧內各層均滿足 Branch Protection 且下方層也已就緒後，可在 GitHub 網頁一鍵合併整棧，或使用：
gh stack merge
合併前官方要求：目標層及其下方所有層都已通過審查與 CI，且棧內歷史保持線性。
與 Merge Queue、代碼審查的配合¶
對啓用 Merge Queue 的團隊，堆疊 PR 的價值在於：John Resig 在公告中的反饋——一次性將多層 PR 送入 Merge Queue 合併，省去了逐層排隊、手動 rebase base 的摩擦。
審查側，TED CTO Andy Merryman 提到：AI 提升開發產出後，PR 體積膨脹成爲新瓶頸；堆疊 PR 把 Review 拆成更小、有依賴順序的邏輯塊，反饋循環更短。WHOOP 工程師 Mayank Saini 則強調，整棧一鍵合併後，體驗「像原生 GitHub 能力，而不是外掛工具」。
實踐上可遵循幾條官方隱含的最佳實踐：
- 每層聚焦單一 concern：schema 變更、API、UI 分棧，Reviewer 按專長並行看不同層。
- 保持棧深度可控：Merge Queue 對超大棧可能拆成多個 merge group，層數過多會增加協調成本。
- CI 優化：workflow 可通過
github.event.pull_request.stack讀取棧元數據，避免對每層重複跑全量集成測試（詳見官方「Optimizing CI for stacked pull requests」文檔）。
和第三方堆棧工具的關係¶
Graphite、Sapling、Jujutsu 等在本地分支管理上各有優勢；GitHub 公測後，平臺側的 Stack UI、Protection 評估、Merge Queue 集成由官方接管，第三方工具仍可負責本地 workflow，再與 gh stack submit 或網頁端銜接。
若團隊已在 Trunk-based Development 下習慣小步提交，堆疊 PR 相當於把「小步」映射成「小 PR 鏈」，trunk 始終是最終歸宿；若仍習慣長期 feature 分支，可先從一個三層以內的試點棧開始，熟悉 rebase 與 Protection 規則再擴大。
小結¶
2026 年 7 月 30 日起，GitHub Stacked Pull Requests 公測向全體倉庫 rollout，配合 gh extension install github/gh-stack 即可在終端完成建棧、rebase、開 PR、合併。它針對的是「大 PR 難審查、多分支 rebase 地獄」這一老問題，把堆疊開發模型收進 GitHub 原生 PR、Checks 與 Merge Queue 體系。
功能仍處於 Public Preview，API 與行爲可能調整；更多細節見 Stacked pull requests 文檔，反饋可提交至 GitHub 官方 stacks discussion。
