摘要： GitHub 於 2026 年 7 月 30 日宣布 stacked pull requests 進入公開預覽，並逐步開放所有倉庫。堆疊由多個有順序、範圍集中的 PR 組成，可平行審查、逐層合併或整疊合併；既有 review、checks 與合併條件持續運作，merge queue 支援則會陸續推出。
GitHub 在 2026 年 7 月 30 日宣布，stacked pull requests（堆疊 PR）已進入公開預覽，並在接下來幾天內逐步對所有倉庫開放。這項能力長在平台層級，並非外掛：你原本就在用的 review、checks 與合併條件全部照常運作，唯一不同的是，大改動不再只能硬塞進單一個巨大 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，它上方的 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」。