如果你曾經提交過一個包含數千行程式碼、橫跨十幾個檔案的巨型 Pull Request (PR)，你一定知道那種痛苦：審核者（Reviewer）因為資訊量太大而失去焦點，反饋品質下降，而你則在等待審核的過程中，必須停下開發進度，或者在舊的分支上繼續開發，導致最後合併時面臨極其複雜的衝突。
為了改善這個問題，GitHub 推出了原生支援的 Stacked PRs（堆疊式 PR）工作流。對於剛接觸大型專案的工程師來說，這不僅是一個新功能，更是一種改變開發習慣的模式。
什麼是 Stacked PRs
在傳統的工作流中，我們通常會從 main 分支切出一個 feature 分支，開發完成後提交 PR 並合併回 main。但如果一個功能很大，開發者往往會選擇將所有變更塞在同一個 PR 中，這就是所謂的巨型 PR。
Stacked PRs（也稱為 Dependent PRs 或 Chained PRs）採取的是鏈式結構。簡單來說，你不再將所有程式碼一次性提交，而是將大功能拆解成多個小層級。第一個 PR 針對 main 分支，而第二個 PR 則針對第一個 PR 的分支，第三個針對第二個，以此類推。
這樣做最大的好處是將單個 PR 的規模控制在 200 到 400 行之間。數據顯示，這個規模的 PR 缺陷率能降低 40%，且審核速度快上三倍。開發者可以在第一層 PR 等待審核的同時，直接在該分支上繼續開發第二層，而不需要等待合併。
技術實作與 gh stack 工具
手動維護這種鏈式分支在 Git 中是非常痛苦的。如果你在第一層 PR 根據審核建議修改了程式碼並進行 Rebase（重新定義基底），後續所有依賴它的下游分支都會失效，你必須手動地對每一個分支重新執行 Rebase 並 Force Push。
為了自動化這個過程，GitHub 推出了 gh stack 這個 CLI 擴充工具。其中最核心的指令是 gh stack sync，它能自動將 Rebase 的變更級聯（Cascade）傳遞到整個堆疊中，並原子化地更新所有相關分支。
此外，GitHub 在 UI 介面上增加了 Stack Map（堆疊地圖），讓審核者能清楚看到 PR 之間的依賴順序，而不需要在多個分頁間切換來追蹤脈絡。在 CI（持續整合）與分支保護規則方面，系統會將最終目標設定為 main 分支，確保即使在鏈式開發中，最終合併的品質依然受到管控。
實務上的限制與挑戰
雖然 Stacked PRs 看起來很完美，但在實際操作中仍有幾個技術坑洞需要注意。
首先是合併策略的衝突。如果你在中間層級使用了 Squash Merge（將所有提交壓縮成一個）或 Rebase Merge，這會改變 Commit Hash（提交雜湊值），進而破壞下游分支的追蹤鏈結。因此，在鏈式 PR 的中間環節，通常建議使用標準的 Merge Commit。
其次是認知負荷。雖然拆分 PR 能降低審核難度，但如果堆疊層數過多（例如超過 4 層），開發者追蹤依賴關係的心智成本會大幅增加，反而抵消了拆分帶來的好處。
最後是 AI 的整合。目前的趨勢是利用 AI Agent（AI 代理人）來協助拆分。透過安裝相關指令，AI 可以幫你將一個巨大的 Diff（程式碼差異）自動切割成符合邏輯的小層級，確保每一層只做一件事情且具備獨立的意義。
總結與觀點
GitHub 的這項更新實際上是在將 Meta 或 Google 等大廠內部使用十餘年的開發模式主流化。雖然市場上已有像 Graphite 這樣的第三方工具提供更成熟的 Merge Queue（合併隊列）與 IDE 整合，但 GitHub 原生支援的最大優勢在於 UI 的整合。審核者不需要安裝額外插件或建立第三方帳號，就能直接在 GitHub 介面中看到完整的開發脈絡。
對於 Junior 工程師而言，學習使用 Stacked PRs 不僅是學習一個工具，更是學習如何將複雜問題拆解為可管理、可審核的小單元，這是提升團隊開發效率與程式碼品質的關鍵實務。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。