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