前言¶
大型功能改動往往意味着一個體積龐大的 Pull Request：審查者需要面對上千行 diff，CI 跑很久，反饋週期被拉長，合併衝突也更容易堆積。不少團隊會手動把改動拆成多個有依賴關係的分支和 PR，但 rebase、對齊 base 分支、確認每層 CI 狀態，這些維護成本並不低。
2026 年 7 月 30 日，GitHub 宣佈 Stacked Pull Requests（堆疊 PR） 進入公測（Public Preview）。該功能把大型變更拆成有序、可獨立審查的 PR 鏈，並在 Web、CLI、移動端及 Copilot Agent 中統一管理；審查者可以並行 review 不同層，合併時也能一鍵落地整棧。本文基於 GitHub 官方 Changelog 與文檔，梳理這一功能的核心機制與上手方式。
說明：堆疊 PR 目前處於公測階段，功能與 API 可能調整；Merge Queue 對堆疊 PR 的支持將在未來數週內逐步推出。
什麼是堆疊 PR¶
堆疊 PR 是指同一倉庫內兩個及以上 Pull Request 形成的依賴鏈：
- 最底層（bottom）的 PR 以主幹分支（通常是
main）爲 base； - 其上每一層 PR 的 base 都是下一層 PR 所在的分支。
示意結構如下：
┌── 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 只展示「當前分支相對下一層分支」的 diff，而不是整坨改動的累積差異。共享類型、數據庫 schema 等基礎改動放在較低層；依賴它們的 API、UI 邏輯放在更高層。官方文檔強調一條原則：若 A 層代碼依賴 B 層，則 B 必須在同一層或更低層。
爲什麼社區討論熱度高¶
堆疊 PR 並非全新概念——Graphite、ghstack 等工具早已在 GitHub 生態裏實踐類似工作流。此次 GitHub 原生支持後，幾個痛點被直接解決：
- 分支維護：依賴鏈上的 rebase 由 GitHub 服務端或
gh stackCLI 自動級聯處理，合併底層 PR 後，上層分支會自動 rebase 並 retarget。 - 規則與 CI：過去鏈式 PR 往往只有最底層能完整觸發 branch protection 和 CI；現在 stack 中每一層都會執行與 base 分支（通常是
main）相同的保護規則和 PR 觸發的 Actions 檢查。 - 審查上下文：Web 端 PR 頂部會顯示 stack 圖標與 stack map，審查者能清楚看到當前層在整個改動中的位置。
在 AI 輔助編碼普及的背景下，這一功能也被官方明確對標「高產出開發」場景：Agent 完成一個任務後立刻在上一層繼續下一個任務，每層對應一個 PR，避免把不相關改動揉進同一分支。
Next.js 負責人 Tim Neutkens、jQuery 作者 John Resig 等在 GitHub 公告中均提到，堆疊 PR 幫助團隊在保持小步審查的同時推進大功能；John Resig 還特別提到配合 gh CLI 與 Agent skill 可以一次性將多層 PR 送入 Merge Queue。
在哪裏能用¶
根據官方文檔，堆疊 PR 目前支持：
| 入口 | 說明 |
|---|---|
| GitHub 網站 | stack map、層級導航、一鍵合併整棧 |
| GitHub CLI | gh stack 擴展，負責本地創建、rebase、提交 |
| GitHub Mobile | 移動端查看與操作 stack |
| Webhooks / REST / GraphQL | 自動化集成，payload 含 stack 對象 |
| Copilot 等 Agent | 通過 gh-stack skill 驅動 CLI |
暫不支持：GitHub Desktop；跨 fork 的 stack（所有分支須在同一倉庫）。
快速上手：gh stack CLI¶
環境要求¶
- GitHub CLI（
gh）2.90.0 或更高，Git 2.20 或更高 - 已執行
gh auth login完成認證 - 對目標倉庫具備 push 權限
安裝擴展¶
gh extension install github/gh-stack
若要在 Copilot 等 AI Agent 中使用，可額外安裝 skill：
gh skill install github/gh-stack
創建第一個 stack¶
- 在倉庫目錄初始化 stack，CLI 會創建跟蹤記錄並生成第一個分支：
gh stack init
- 在當前層正常寫代碼、提交：
git add .
git commit -m "添加 auth 中間件"
- 開始下一個邏輯單元時，在 stack 頂部新增分支：
gh stack add feat/api-routes
# 繼續開發並 commit ...
- 推送所有分支：
gh stack push
- 創建 PR 並在 GitHub 上鍊接爲 stack：
gh stack submit
第一條 PR 的 base 是 main，後續每層 PR 的 base 爲下一層分支。審查者每層只看到自己負責的那部分 diff。
- 隨時查看 stack 全貌：
gh stack view
常用命令速查¶
| 命令 | 作用 |
|---|---|
gh stack add -Am "MESSAGE" |
暫存、提交，並在需要時創建新層 |
gh stack sync |
拉取遠端、rebase、推送並同步 PR 狀態 |
gh stack rebase |
對 stack 執行級聯 rebase |
gh stack merge |
合併一層或多層 stack PR |
gh stack checkout <PR號> |
按 PR 號切換 stack 中的分支 |
gh stack unstack |
解除 stack 關聯 |
Web 端審查與合併¶
打開 stack 中的任意 PR，頁面頂部會顯示層級編號與 stack map，可一鍵跳轉到其他層。不同審查者可以並行 review 不同層，互不阻塞。
合併規則要點：
- 必須從底層向上合併；
- 合併頂層 PR 時，其下所有未合併層會一併落地；
- 若只合並中間某層，該層及以下合併，上層 PR 保持打開並自動 retarget；
- 支持 merge commit、squash、rebase 三種合併方式，且與 Merge Queue 兼容（支持正在逐步 rollout）。
與 Merge Queue、Copilot 的關係¶
Merge Queue 用於在合併前排隊跑 CI、避免主幹衝突；官方表示 stack 的 Merge Queue 支持正在分階段推出。John Resig 在公告中的用例是「一次性將 5 個堆疊 PR 送入 merge queue」，說明目標場景是：多層改動各自通過審查與檢查後，作爲整體有序進入主幹。
Copilot 側則通過 gh-stack skill 讓 Agent 理解 stack 語義——創建分支鏈、push、submit、rebase 等操作都可以被 Agent 調用，適合 AI 連續產出多步改動的場景。GitHub 文檔也提供了「Stack AI-generated code in pull requests」教程，指導如何把 Agent 產出組織成 stack。
使用時的注意點¶
- 公測階段：API 有更新，若通過 REST API 合併 stack，需使用支持 stack 的新版 merge API（文檔標註 API 版本
2026-03-10）。 - 倉庫範圍：不支持 fork 倉庫之間的 stack。
- 拆分粒度：每層應是可獨立審查的邏輯單元；切換前後端、核心邏輯與測試等「不同關注點」時適合開新層。
- ** rollout 節奏**：功能在未來數天內向所有倉庫開放；Merge Queue 集成需等待後續更新。
小結¶
GitHub 堆疊 PR 把「大 PR 難審、鏈式分支難維護」這一老問題收進了原生工作流：小層並行審查、規則與 CI 逐層生效、合併時一鍵落地整棧，rebase 由平臺託管。對習慣 Graphite 等第三方工具的團隊，這是一次「不用換平臺也能 stack」的選項；對正在用 Copilot 加速產出的團隊，則提供了一條把 Agent 產出結構化入庫的路徑。
若你所在團隊正被巨型 PR 拖慢節奏，可以先 gh extension install github/gh-stack，用一個小功能試水 stack 拆分，再在 Web 端體驗 stack map 與整棧合併。公測期間歡迎在 GitHub 的 stacks discussion 中反饋使用體驗。
