GitHub近日發布了堆疊PR（Stacked PRs）功能，該功能目前處於私有預覽階段，旨在幫助開發者更輕鬆地管理大型拉取請求，並加快整個代碼審查流程。
堆疊PR允許一個拉取請求基於前一個拉取請求構建，從而形成一條"堆疊鏈"。鏈中的每個拉取請求都可以獨立進行審查和合併，但前提是其下方的所有拉取請求均已完成合併。此外，用戶也可以選擇將整個堆疊一次性合併。
堆疊PR的核心優勢在於鼓勵開發者提交更小粒度的拉取請求，從而降低審查難度。官方文檔指出："堆疊中的每個分支應代表一個獨立的、符合邏輯的工作單元，可以被單獨審查。"
然而在實際開發中，這一目標往往難以實現。開發者通常希望在等待前序代碼合併期間持續推進工作，而不願因等待審查而中斷進度。為此，他們往往會在獨立分支上持續開發直至功能完整，最終提交一個涉及大量文件變更的巨型拉取請求，給審查工作帶來極大負擔。
堆疊PR功能雖然對GitHub而言是全新能力，但在其他代碼管理與審查系統中早有類似實踐，通常被稱為"堆疊差異（Stacked Diffs）"。其中最具代表性的是由Facebook的Evan Priestley和Luke Shepard於2007年開發的Differential工具。Priestley曾表示："我花了大量時間等待代碼審查，這正是我構建這個工具的主要動力。"Differential後來成為Facebook內部工具套件Phabricator的核心組件，並於2011年以開源形式對外發布。開源版Phabricator已於2021年停止更新，但其分支項目Phorge目前仍在積極維護中。
在使用堆疊PR時，開發者的工作流程與傳統方式存在顯著差異。堆疊最底層的PR通常直接基於主分支創建，而非獨立分支。曾在Facebook擔任工程師的Jackson Gabbard（2006年至2016年）在一篇詳細說明文章中寫道："使用過Phabricator堆疊差異工作流的開發者普遍非常喜愛這種方式，並且在去到新的地方後也會主動尋找類似的工具。"
在Hacker News上，社區對這一功能的討論總體持積極態度。不過也有開發者指出："我不太明白為什麼需要這個命令行工具（CLI），Git本身近幾年的更新已經可以原生支持這種工作流。"此處提及的CLI正是GitHub專屬擴展工具gh stack。儘管如此，將該功能整合進GitHub仍是一項重大改進，而CLI的存在也大幅簡化了使用門檻。負責該功能開發的GitHub工程師Sameen Karim表示："CLI完全是可選的，你完全可以通過圖形界面創建堆疊PR。"
在AI層面，GitHub同樣有所布局。Karim在LinkedIn上表示："瓶頸已不再是寫代碼，而是審查代碼。堆疊PR有助於解決這一問題。"他還透露，堆疊CLI同樣面向AI智能體使用場景進行了專項設計。
Q&A
Q1：堆疊PR（Stacked PRs）是什麼？它解決了什麼問題？
A：堆疊PR是GitHub新推出的功能，允許多個拉取請求以堆疊形式相互依賴，每個PR可獨立審查和合併。它主要解決了開發者在等待代碼審查時無法持續推進工作的問題，避免了因功能未拆分而提交龐大、難以審查的拉取請求的情況，從而提升代碼審查效率。
Q2：堆疊PR和Phabricator的堆疊差異功能有什麼關係？
A：堆疊PR的概念源於Phabricator的"堆疊差異（Stacked Diffs）"工作流。Phabricator是Facebook於2011年開源的內部工具套件，其核心組件Differential由Evan Priestley和Luke Shepard於2007年開發，專門用於解決代碼審查效率問題。許多熟悉這一工作流的開發者對其評價極高，GitHub此次將類似功能整合進平台，是對這一成熟工作流的傳承與發展。
Q3：使用堆疊PR必須用命令行工具（CLI）嗎？
A：不是必須的。GitHub提供了專屬CLI擴展工具gh stack來輔助管理堆疊PR，但負責該功能開發的工程師Sameen Karim明確表示，CLI完全是可選項，用戶可以直接通過GitHub的圖形界面來創建和管理堆疊PR，無需使用命令行工具。
