寫代碼的人都懂：GitHub 開始解決“大 PR 地獄”

作者 | Matt Saunders

譯者 | 田橙

GitHub 已通過一個名為 gh-stack 的新 CLI 擴展推出原生的堆疊式拉取請求工作流，填補了多年來一直由第三方工具彌補的空白。該方案的目的是解決大型拉取請求難以審查、合并緩慢且容易產生沖突的問題；GitHub 表示，在這種情況下，審查者會丟失上下文，反饋質量下降，整個團隊的效率也會隨之降低。

堆疊式拉取請求（有時也稱為依賴式或鏈式 PR）是一種代碼評審模式，在這種模式中，每個分支并不是直接指向主分支，而是按順序指向其下方的前一個分支。該方法使開發者能夠在較早層仍在審查時，繼續推進功能后續層的開發工作。

我曾花費大量時間等待代碼評審完成，這也是我構建這個工具的主要動機。Phabricator Differential 的共同創建者 Evan Priestley 表示。

發布公告中引用的研究表明，這種工作流具有可量化的收益。一項對 150 萬個拉取請求的分析發現，200 到 400 行之間的 PR 缺陷減少了 40%，審批速度比更大的 PR 快了三倍。堆疊式方法的設計目標，是即便底層功能規模較大，也能讓每個單獨的 PR 保持在這一范圍內。

gh-stack 擴展與現有的 GitHub CLI 集成，并處理了歷史上讓堆疊式工作流難以手動維護的各種機制。其核心命令 gh stack sync 會在整個堆棧中級聯執行 rebase，并在對較早層進行更改后，以原子方式強制推送每個分支。GitHub 的拉取請求界面新增了堆棧映射，使審查者可以在各層之間導航；分支保護規則則針對最終目標分支生效，而不是每個 PR 的直接基線分支。CI 也會像每個 PR 直接指向主分支一樣運行。

該擴展還集成了 AI 代理。運行 gh skill install github/gh-stack 可以讓兼容的 AI 編碼代理學會如何創建和管理堆棧，從而能夠將大型 diff 拆分為多個層，或在任務一開始就采用堆棧方式進行開發。

CLI 是完全可選的，你也可以僅通過 UI 創建堆疊式 PR。 GitHub 的 Sameen Karim 表示。

堆疊式 diff 模式在軟件開發中并非新事物。Meta 和 Google 早在近十年前就采用了類似的工作流，并構建了包括 Phabricator 和 Gerrit 在內的自定義工具。Simohamed Marhraoui 早在 2021 年就在 LogRocket 上撰文指出，該方法已適用于 GitHub，但需要注意合并策略：squash 和 rebase 合并都會重寫提交哈希，從而破壞用于在堆棧中關聯分支的身份追蹤。Marhraoui 提到的限制——在鏈式 PR 的中間層只能使用標準的 merge commit——在 GitHub 上的任何堆疊式工作流中仍然是一個現實問題。

在發布后不久，Alan West 在 dev.to 上撰文指出，git 本身并未提供任何機制來管理依賴分支之間的關系。“當你對第一個分支執行 rebase 時，所有下游分支也都需要手動 rebase，”West 寫道，并描述了一個五步的流程，開發者在每次審查者要求修改早期 PR 時都必須重復執行。West 認為，一個堆棧中包含三到四個 PR 是較為實際的上限：“超過這個數量，跟蹤依賴關系所帶來的認知負擔將開始超過評審帶來的收益。”

GitHub 的主要競爭對手 Graphite 由前 Meta 工程師創立，目前已無需等待列表即可使用。Graphite 提供支持堆棧的合并隊列、基于 Web 的評審界面、VS Code 集成以及 CLI。其免費版本包含 CLI 和堆疊工作流；付費方案起價為每位用戶每月 20 美元。Joe Buza 在 2026 年 2 月于 LinkedIn 上表示，他一直在引導 AI 編碼代理使用類似 Graphite 的工作流，將功能拆分為堆疊式 PR，將每個 PR 限制在 200 行以內，并要求每一層“只完成一個邏輯目標，并且自身具備完整意義”。

社區對 GitHub 此次發布的反應不一。Hacker News 上關于該發布的討論帖獲得了 516 分和 282 條評論。其中一種觀點認為，這是對長期以來只在大型工程組織中使用的模式的一種主流認可：“堆疊式 diff 在 Meta 已經存在十年，很高興看到 GitHub 終于來到 2016 年。”另一種持懷疑態度的觀點則質疑這種工作流是否適合 GitHub 的基礎設施：“要么變更是獨立的，那就使用獨立的 PR；要么它們是依賴的，那單獨審查就沒有意義。”還有一種批評意見（由 ByteIota 總結）指出，squash 合并的兼容性以及級聯 rebase 沖突仍是尚未解決的技術問題，而 Graphite 已經有數年時間來處理這些問題。

GitHub 進入堆疊式 PR 領域的一個顯著特點在于：其堆棧映射和規則執行邏輯直接內置于拉取請求 UI 中，這意味著審查者無需額外賬戶或擴展即可查看上下文。官方文檔指出，CLI 是“完全可選”的，堆棧也可以直接通過 GitHub 的 UI 或 API 創建。這樣的原生集成是否足以吸引已經使用 Graphite 的團隊，或將該工作流推廣給從未嘗試過堆疊方式的開發者，很大程度上取決于 GitHub 在私有預覽期間如何處理各種邊界情況。

該功能于 2026 年 4 月 13 日進入私有預覽階段，開發者需要加入等待列表后，擴展才能在其倉庫中生效。InfoQ 的相關報道還包括：2026 年 2 月關于 GitHub 重構基礎設施策略執行的分層防御機制的文章，以及 2026 年 4 月關于 Anthropic 為 Claude Code 引入基于代理的代碼評審的報道，該報道發現，在采用自動化評審工具后，針對變更超過 1000 行的 PR，其具有實質性評審評論的比例從 16% 提升至 84%。

https://www.infoq.com/news/2026/04/github-stacked-prs/

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？