編按：本文綜合整理自 GitHub Changelog、InfoQ 報導、GitHub 官方 gh-stack 指南 與 Hacker News 討論串，並加入 Siami 編輯部觀點與分析。
GitHub 於 2026 年 7 月 30 日宣布將 Stacked Pull Requests（堆疊式 PR） 正式推進到 公開預覽（Public Preview） 階段。所有 repository 在接下來幾天內將陸續啟用，Merge Queue 支援 也在未來幾週內分階段推出。這是 GitHub 首次把「依賴鏈式 PR」這個進階工作流從第三方工具（如 Graphite、Sapling、ghstack）搬進官方產品線，等於宣告大型代碼審查的新時代正式來臨。
堆疊 PR 到底是什麼
傳統 GitHub 工作流要求每個 PR 只能合併到 main。當一個 feature 涉及上百個檔案、上千行變更時，reviewer 只能被迫審一份「巨石 PR」，或者把改動拆到多個 branch、手動 rebase——後者一旦中間層被改，後面所有層都要跟著 rebase，工程師常被困在「rebase 地獄」。
堆疊 PR 的核心想法很簡單：每個 PR 不再合併到 main，而是合併到位於它「正下方」的那個 PR。換句話說，整個 feature 被切成多個垂直的小 PR，每個 PR 都聚焦於一個明確的修改層。你可以同時審第 2 層和第 4 層，也可以一次合併整個堆疊——GitHub 會自動處理 rebase。
Vercel Next.js 負責人 Tim Neutkens 在官方文檔中表示：「我們在 Next.js 上使用 GitHub 堆疊 PR 已經好幾個月了。它讓我們能在推出大型功能的同時引入更小的獨立改變，讓 PR 審查變得更容易。」
具體效益在三個面向：
- 並行審查：團隊可以對同一個堆疊的不同層同時 review，互不阻塞
- 保留品質：每層 PR 都搭配既有的 branch protection、required checks，不會繞過任何規則
- 彈性合併：可以一次合併整個堆疊，也可以只合併其中幾層，上層的 PR 會自動 rebase 到新的 base
三種操作路徑：CLI、UI、AI Agent
GitHub 刻意把堆疊 PR 設計成「CLI 完全 optional」——使用者可以純粹透過 Web UI、API、CLI 擴充，或者由 AI 代理來建立和管理堆疊。
1. CLI 擴充 gh-stack
gh extension install github/gh-stack這是 GitHub 官方維護的 GitHub CLI 擴充（GitHub 內 GitHub 員工開發）。核心指令 gh stack sync 能在修改最底層後，atomic 地 cascade rebase 整個堆疊並 force-push 每個 branch——這過去要手動處理 5 個步驟，現在一個指令解決。
2. Web UI
直接從 GitHub.com 上的 PR 頁面就能建立堆疊，沒有任何 CLI 經驗也能用。最重要的是 stack map——在 PR 頁面頂端會顯示這個堆疊的整體視覺化圖，reviewer 一打開就看到自己審的這層在整體架構的哪個位置。
3. AI Agent Skill
執行 gh skill install github/gh-stack 可以把堆疊 PR 的工作流教給相容的 AI 編碼代理（如 GitHub Copilot CLI）。代理會自動把一個大型 diff 拆成多個層、從任務一開始就以堆疊方式開發。
jQuery 創辦人 John Resig 在 X 上公開讚揚：「新的 GitHub Stacked PRs preview 令人難以置信。一次把 5 層堆疊 PR 全部送進 merge queue！A+++！這消除了太多摩擦（gh CLI 工具 + agent skill 也幫了大忙）。」
為什麼這件事重要
堆疊 PR 在 2026 年正式進入主流，原因有三：
🚨 AI 代理讓 PR 體積爆炸
2025 年下半開始，AI 編碼代理（Cursor、Claude Code、Copilot）開始大量產出 PR。當一個 PR 超過 1000 行，人類 reviewer 的有效反饋率就斷崖式下跌——InfoQ 4 月的報導引用 Anthropic 的內部研究：Claude Code 上線後，超過 1000 行的 PR 上「具實質意義的 review 意見」比例從 16% 跳到 84%；但反過來說，剩下的 16% 那種純人工審 1000+ 行 PR 的品質是糟糕的。堆疊 PR 把每層控制在 200–400 行，正好落在研究顯示「缺陷率最低、批准速度最快」的甜蜜區。
🚨 GitHub 的 graph 是無可取代的護城河
第三方工具（Graphite、ghstack、Sapling）雖然早就有堆疊功能，但它們都要使用者註冊額外帳號、裝額外 CLI、登入額外 dashboard。GitHub 把堆疊邏輯 直接寫進 pull request UI 本身——reviewer 不需要裝任何東西 就能看到 stack map。這對從未嘗試堆疊的開發者來說，是零摩擦的入口。
🚨 AI Agent Skill 是新戰場
gh skill install github/gh-stack 把堆疊工作流變成 AI 代理的「原生技能」。這代表未來所有用 AI 寫程式的工作流，可能預設就是堆疊 PR——主流化從此開始。Graphite 雖然有 gt CLI，但他們無法教 AI 代理怎麼用 GitHub 原生功能，因為這些功能現在才存在。
對手不是 Graphite，而是「非堆疊工作流」
商業堆疊 PR 工具 Graphite（後來被 Cursor 收購）從 2021 年起就提供 stack-aware merge queue、Web review 介面、VS Code 整合、CLI。付費方案 20 美元/月起。Graphite 工程背景是前 Meta 員工——他們把 Meta 內部用多年的工作流商品化給外界。
GitHub 4 月進私有預覽時，HN 討論串已經累積 516 分、282 則留言。多數正面評論認為這是「2016 年該做的事 GitHub 終於做了」（堆疊 diff 在 Meta 已十年），但也有批評：
「要嘛改動是獨立的，那你開多個 PR 就好；要嘛是相依的，那分開審根本沒意義。」—— HN 留言
「squash-merge 相容性與 cascading rebase 衝突仍是未解的技術問題，Graphite 已經花了多年處理。」 —— ByteIota
GitHub 在 FAQ 中明確處理了這些顧慮：
- Squash merge 完全支援：每層 PR 各自產生一個 squashed commit，底層 squash 後上層自動
git rebase --onto到新 base，避免人工衝突 - Merge queue 完全支援：整個堆疊一起進入 queue、由底向上逐個評估；如果某層失敗，該層與所有上層一起退出，不會污染下層
- Auto-merge 暫時不支援：官方說「coming soon」，目前必須手動 merge
數據解讀與質疑
數字怎麼讀
GitHub 引用了一項內部分析（InfoQ 報導轉述）：1.5 百萬個 PR 中，200–400 行的 PR 缺陷率比巨型 PR 低 40%、批准速度快 3 倍。這是堆疊工作流的核心論據。但要注意：
- 該研究沒有公開方法論、無審查同行評議
- 不是因果證明：可能本來就傾向把簡單改動拆成小 PR 的團隊，review 文化本來就比較好
- 樣本限於 GitHub 平台內部，可能有選擇偏差
質疑聲音
部分 HN 用戶指出三個真實痛點：
- 3–4 層以上就太複雜：dev.to 工程師 Alan West 評論「超過這個層數，dependency tracking 的認知負擔會蓋過審查效益」
- CI 成本翻倍：每層跑一次完整 CI，5 層就是 5 倍成本。對 monorepo 的小團隊可能是隱性開銷
- 跨 repo 堆疊仍未支援：HN 留言 camilomatajira 反映——「我想要這堆疊同時包含 backend PR、frontend PR、ArgoCD PR 按特定順序推進」，目前還做不到
該怎麼開始
對個人開發者：
gh extension install github/gh-stack
gh stack create my-feature對團隊 lead：先在一個 monorepo 子目錄試一個 3 層的堆疊，驗證 CI 成本與 reviewer 體驗後再推廣。Merge queue 對堆疊的支援還在分階段推出，生產環境關鍵 PR 先別全部倚賴。
Stacked PRs 正在向所有 repo 公開預覽，幾天內全部啟用。Merge queue 支援在未來幾週分批上線。
GitHub 員工 Sameen Karim 在 HN 回應：「CLI 是完全 optional 的，你可以純粹透過 UI 開堆疊 PR。」
網友熱門留言 (6)