重新定義拉取請求（Pull Request）

背景

這場討論源於 Lubeno 開發者發表的一篇關於重新設計拉取請求（Pull Request, PR）流程的文章。作者主張透過「堆疊式 PR」（Stacked PRs）與更精細的提交管理，解決傳統 PR 體積過大、難以審閱且導致開發流程中斷的問題，並藉此推廣其開發的程式碼審閱平台。

社群觀點

針對這項提議，Hacker News 社群展開了多維度的辯論。支持者認為堆疊式 PR 是現代開發流程的必然趨勢，特別是對於追求高效率的團隊。這類工作流允許開發者在等待審閱的同時，基於尚未合併的程式碼繼續開發，而不必停工等待。Steve Klabnik 等資深開發者指出，堆疊式 PR 的核心價值在於將大型變更拆解為可獨立審閱的小型提交，這不僅減輕了審閱者的負擔，還能讓不同專長的工程師（如前端與後端）專注於與其相關的特定提交，而非被迫閱讀整份龐大的差異清單。

然而，反對意見則聚焦於流程的複雜性與潛在風險。部分留言者質疑，在未經審閱的基礎上繼續構建功能，萬一底層架構被否決，將導致後續工作全部白費。他們認為傳統的線性開發流程雖然較慢，但能確保每一步都穩固。對此，支持者反駁稱，如果開發者在提交 PR 時還不確定基礎架構是否正確，那是溝通或技術能力的深層問題，而非工具的問題。此外，Jujutsu（jj）等新一代版本控制工具的出現，被認為能有效解決手動重排提交（rebase）的繁瑣，讓堆疊式開發變得更加自然。

除了技術流程，討論也延伸到了 AI 在程式碼審閱中的角色。有觀點認為，與其要求開發者手動拆分 PR，不如利用大型語言模型（LLM）自動將龐大的變更拆解為易於消化的區塊。這種「自動化拆解」被視為比改變人類工作習慣更具可行性的方案。同時，也有開發者對 SaaS 形式的審閱工具表示疲勞，傾向於使用「在地優先」（Local-first）的工具，以便更好地與本地開發環境及 AI 代理整合。

有趣的是，這場討論也觸發了對 GitHub 長期缺乏原生堆疊式 PR 支持的批評。儘管有消息指出 GitHub 正在測試相關功能，但許多人認為其目前的介面在處理跨倉庫或複雜提交鏈時依然力不從心。最後，一部分極簡主義者則主張回歸「直接提交到主分支」（Trunk-based development）的傳統，認為過度依賴 PR 審閱機制反而成了團隊溝通的障礙，真正的持續集成應該是頻繁且小規模的直接合併。

延伸閱讀

在討論中，參與者提到了多個與堆疊式 PR 及版本控制相關的工具與資源。Jujutsu (jj) 被多次提及，這是一款旨在改善 Git 使用體驗並原生支持堆疊式工作流的版本控制系統。Graphite 則是另一個專注於堆疊式 PR 的知名平台。此外，ERSC 被提及為正在開發中的新一代原始碼管理工具。針對 Git 用戶，留言者也建議開啟 RERERE 與 autostash 功能，以減少處理衝突時的重複勞動。最後，有開發者分享了 GitHub 正在進行的堆疊式 PR 私度測試消息，顯示主流平台正試圖回應這類需求。