GitHub Draft Pull請求支援新的協作流程

GitHub已經引入了draft pull 請求來處理正在進行的工作場景，在這些場景中，你可能希望在程式碼準備好接受審查之前先開啟PR或者與您的隊友交流一下。

在建立新PR時，現在可以使用下拉選單選擇是建立普通的pull請求還是draft pull請求。draft pull請求與普通請求明顯不同，它不能合併。你可以通過新增評論或要求其他團隊成員檢視並提供反饋來自由地修改draft PR。重要的是，draft PR不會每有一處修改就給所有的程式碼所有者發通知。這是draft PR能夠實際用起來的一個關鍵特性，否則，那些不怎麼需要關注的修改也會全給他們發通知。

當你完成一個draft PR時，可以簡單地把它標記為“已準備好審查”，就能將其狀態設定為正常的PR了，或者如果它沒有什麼進展，你可以將其廢棄。

一場在Hacker News上的討論為這個新特性提供了更多的背景和基本原理。許多使用者表示，他們已經通過在PR名稱中新增“WIP”或“DO NOT MERGE”來建立draft pull 請求了。這表明，draft PR是一種將某種常見但非正式的實踐進行正式化的方法。

這些PR的作用是促進討論，開始知識共享，並向其他開發人員更清楚地介紹自己的進展情況，而不是讓他們更細緻地檢查分支。但又是我絕對不想合併的那個。

使用者tedivm指出，在開發新特性時，不能將draft pull 請求視為特性分支的替代方法。因此，所有當前的CI/CD良好實踐都不受draft PR的影響。實際上，他建議你仍然建立特性分支，並在這個分支不斷提交，頻繁地將其推送到你的儲存庫，但是你可以在任何時間點建立draft pull 請求，其主要目標有兩個：展示特定特性的工作已經完成和幹到什麼地步了；提供一種簡單的方法來檢查所涉及的更改，並讓人們儘早對程式碼本身進行註釋。

使用者gfosco特別強調了draft PR的價值，當你參與一些大型和複雜的專案時，你無權建立分支，因此只能在自己的fork上開展工作。在這種情況下，讓其他專案成員檢查你的fork或分支以獲得反饋實際並非一個可行的方法。相反，建立一個draft PR可以無縫地協作。

其他評論指出，他們更喜歡通過其他方法(如wiki、文件或bug跟蹤器)管理此類討論。

GitHub的draft PR並不是首創，因為GitLab已經提供了一個類似的功能，叫做WIP合併請求。類似地，用於Android開發的原始版本管理系統Gerrit也已經提供了與draft pull 請求相同的概念。

檢視英文原文：GitHub Draft Pull Requests Enable New Collaboration Workflows