GitHub 堆疊式 PR：原生支援順序程式碼審查

背景

GitHub 最近推出了一項名為 Stacked PRs 的原生功能，目前正處於私人預覽階段。這項功能允許開發者將多個拉取請求（Pull Request）按順序堆疊，讓每個 PR 代表一個專注的變更層級，既能獨立進行代碼審查，最終又能一鍵合併。這項更新旨在解決長期以來在 GitHub 上處理大型功能開發時，分支依賴關係複雜且難以審查的痛點。

社群觀點

在 Hacker News 的討論中，這項功能引發了兩極化的反應。許多曾使用過 Phabricator 或 Gerrit 等工具的資深開發者對此表示熱烈歡迎，認為 GitHub 終於補齊了在處理複雜變更時的短板。支持者指出，傳統的「一個分支對應一個 PR」模式在處理大型專案時非常笨重，而堆疊式 PR 能鼓勵開發者將工作拆解成更小、更易於消化的片段，這不僅能提高審查效率，也能減少因代碼衝突導致的重構負擔。部分用戶提到，過去為了達成類似效果，必須手動管理多個分支的依賴關係，一旦底層分支發生變動，後續所有分支的變更與重基（rebase）過程簡直是惡夢，而原生支持有望大幅簡化這類工作流。

然而，也有不少開發者對此持保留態度，甚至認為這是對 Git 本質的過度封裝。反對者認為，如果開發者能善用 Git 的提交（commit）功能，並透過逐一審查提交記錄來進行 Review，其實並不需要額外的堆疊層級。他們擔心這會讓版本控制系統變得像早期的 CVS 一樣繁瑣。此外，部分留言者質疑這項功能在多倉庫（Multi-repo）環境下的實用性，認為目前的設計仍侷限於單一倉庫或 Monorepo 架構，無法解決跨多個微服務倉庫進行同步合併的痛點。對於微服務架構的團隊來說，真正的挑戰在於如何協調不同倉庫間的合併順序，而 GitHub 目前的方案似乎尚未觸及這個核心問題。

在技術實踐層面，討論也聚焦於工具鏈的依賴。目前該功能高度依賴 GitHub CLI，這讓部分習慣使用網頁介面或 IDE 插件的用戶感到不便，儘管後續有網友發現網頁端已隱藏了部分操作入口。另外，關於 AI 代理（AI Agents）的整合也成為亮點，有觀點認為堆疊式 PR 能幫助 AI 更好地將複雜任務拆解為邏輯清晰的變更序列，而非一次性產出巨大的代碼差異。最後，GitHub 使用 github.github.com 這種非典型子域名發布文檔的做法，也意外引發了一場關於網路安全意識與官方通訊規範的爭論，部分用戶批評這種做法容易讓使用者混淆，甚至增加被釣魚攻擊的風險。

延伸閱讀

• GitHub Stacked PRs 官方指南：詳細介紹了如何透過網頁 UI 與 CLI 建立堆疊式 PR。
• GitLab Stacked Diffs 文檔：GitLab 提供的類似功能實現，可作為跨平台對比參考。
• Jujutsu (jj)：留言中提到的一款現代版本控制工具，旨在改善 Git 的工作流體驗。
• Octo.nvim：專為 Neovim 用戶設計的 GitHub 整合插件，支持在編輯器內進行 PR 審查。