GitHub stacked PR GA：小 diff 不等於獨立部署單元

把大改動拆成三個 PR，閱讀會更輕鬆。但上層依賴下層時，短 diff 並不意味著可以單獨部署。

10月6日的發布

GitHub 於2026年10月6日宣布正式可用。小 PR 可分別審查並一起合併，支援 github.com 全部方案。

堆疊以一個 merge group 進入 merge queue；merge commit 方式則為每個 PR 建立 commit。測試組合與歷史單元並不相同。

例如 A 加入共用函式，B 在 API 呼叫，C 實作 UI。各 PR 寫明依賴及比較 base。這是流程建議，不是產品自動保證。

只讀 B 可能漏掉 A 缺少的權限檢查。將 diff 審查與 A+B+C 整合驗證分開，並指定最終組合負責人。

GitHub 表示 base 前進後，對除此之外未改動的堆疊 rebase 會保留核准，包括會撤銷舊核准的儲存庫。核准標記與目前整合結果是不同證據。

記錄前後 SHA 和測試的 merge group。確認測試是否重跑、紀錄涵蓋哪個組合；單個綠勾不足以作為發布依據。

函式和 API 必須一起上線時，要在部署計畫保留依賴。每 PR 一個 commit 並不保證單獨 rollback 對剩餘呼叫端安全。

獨立修復無需強行堆疊。綁定可能讓所有工作等待一個延遲測試，應評估維護成本。

GitHub 說 auto-merge 將在未來幾週逐步推出。先看儲存庫目前控制項，不要假設所有帳號今天都有同一按鈕。

preview 回饋推動了導覽和自動化改進。這表明關注度，不保證團隊生產力。請量測自己的審查等待和整合失敗。

選擇函式與呼叫端等兩個依賴明確的 PR。註明 base、依賴和測試指令，約定整合負責人及 rollback 範圍。

同時比較審查節省時間與新增故障。維護成本更高時可回到一般 PR。審查和部署更清楚，比 diff 數量更重要。

發布於10月6日，核對於2026年10月8日。採用前確認儲存庫規則與可用功能。