2026 年 7 月 30 日，GitHub 宣布 stacked pull requests（堆疊 PR）進入公開預覽，幾天內陸續開放給所有倉庫。這是 GitHub 平台層級的功能，不是外掛：你既有 review、checks 與合併條件全部照用，差別在於大改動不再只能擠成一個巨大 PR。
什麼是堆疊 PR
堆疊 PR 是一組有順序的 PR，每個 PR 代表整體改動中的一層。它針對兩個老問題：一是單一巨大 PR 審查曠日廢時、審查品質下滑；二是手工拆多條分支，得不停手動 rebase。改成堆疊之後，團隊可以平行審查一個個小而集中的 PR，最後一次合併整疊。
開始使用：CLI 擴充與 gh-stack skill
GitHub 提供的起點是一行指令：gh extension install github/gh-stack。建好第一層分支與 PR 之後，往上疊新的分支與 PR，每一層的 PR 都以下一層為目標。操作面涵蓋 github.com、GitHub CLI 與行動 App，也可以交給 GitHub Copilot 這類編碼代理，透過 gh-stack skill 直接建堆疊——AI 產出大量程式碼的時代，這條路徑顯然是設計重點。
分層審查與一鍵合併
審查時，打開堆疊中的任一個 PR，只會看到那一層的差異；PR 頂端的堆疊地圖顯示這層在整體改動中的位置，團隊成員可以各自認領不同層、平行審查而不互相卡住。合併則有兩種粒度：合併最上層 ready 的 PR，會連同底下所有未合併的層一次 landing；只合併某個下層時，它上面的 PR 保持開啟，並自動 rebase、重新指向。分支保護與必要檢查照常生效，merge queue 的支援會在接下來幾週逐步推出。
來自大型程式碼庫的回饋
公告裡的實測者名單有分量：Vercel 的 Next.js 負責人 Tim Neutkens 說，過去幾個月用 GitHub 堆疊 PR 開發 Next.js，能在小型單一改動與大型功能之間取得平衡，審查變容易；jQuery 作者 John Resig 直呼「不可思議」，一次把五個堆疊 PR 直接送進 merge queue；TED 的 CTO Andy Merryman 點出核心痛點——AI 讓開發者產能大增，反而讓 PR 大到審查者跟不上，按依賴順序拆成小塊之後，審查不只更快，也更準；WHOOP 的工程師形容它「不像疊在 GitHub 上的工具，而像 GitHub 本身」。
對開發流程的意義
值得注意的不只是功能本身，而是誰把它變成預設。堆疊 PR 工作流之前靠第三方工具與自建腳本撐著，現在由平台內建，等於替「小步提交、逐層審查」背書。對照另一個趨勢——編碼代理一次生成數百行改動，人類審查者的注意力成了瓶頸——堆疊 PR 給了團隊一個官方答案：把代理的輸出按依賴順序切成可審查的層，讓審查速度跟得上生成速度。公開預覽期間，回饋會透過 GitHub 的 stacks 討論區收集；如果它像 merge queue 一樣從預覽走向標配，程式碼審查的單位可能會從「一個 PR」慢慢變成「一疊 PR」。
參考來源
- Stacked pull requests are now in public preview — GitHub Changelog
- Stacked pull requests — GitHub Docs
- Stacked PRs are now live on GitHub — Hacker News
本文由 AI 協助自上述來源整理，經人工審核後發布。