提取請求支援檢閱程式碼並將其合併到單一協作流程中。 開發人員新增功能或錯誤修正後，他們會建立一個拉取請求，以開始將變更合併到上游分支。 然後，其他團隊成員有機會在程式碼最終確定之前審查和批准程式碼。 使用提取要求來檢閱進行中的工作，並取得關於變更的早期意見反應。 但沒有承諾合併這些變更。 擁有者可以隨時放棄提取要求。
檢閱程式碼
作為拉取請求的一部分進行的程式碼審查不僅僅是為了發現明顯的錯誤;這就是測試的目的。 良好的程式碼審查會發現不太明顯的問題，這些問題可能會在以後導致代價高昂的問題。
程式碼審查有助於保護團隊免受不良合併和損壞的組建的影響，這些合併和損壞的組建會降低團隊的生產力。 審查會在合併之前發現問題，保護重要分支免受不必要的更改。
程式碼審查也鼓勵並加強開發人員之間的協作和溝通。 此外，團隊可以獲得主要分支與功能分支之間所有變更的明確的歷史記錄。
在程式碼審查中利用廣泛的審查者來相互交流專業知識並傳播解決問題的策略。 傳播技能和知識使團隊更強大、更有彈性。
提供出色的反饋
高品質的檢閱是從高品質的意見反應開始。 提取請求中獲得良好反饋的關鍵是：
- 讓合適的人員檢閱提取要求。
- 請確定檢閱者知道程式碼的用途。
- 提供可操作的建設性回饋。
- 及時回覆評論。
當您將檢閱者指派給提取要求時，請務必選取正確的檢閱者集。 審閱者應該了解程式碼的工作原理，但也包括在其他領域工作的開發人員，以便他們可以分享他們的想法。
提供變更的清楚描述，並提供修正或功能已正常運作的程式碼建置。 檢閱者應努力就他們不同意的變更提供意見反應。 找出問題並就可以採取不同做法提出具體建議。 此回饋具有明確的意圖，並且易於拉取請求的所有者理解。
提取請求擁有者應該回覆評論、接受建議或解釋他們拒絕應用這些建議的原因。 有些建議很好，但可能超出提取請求的範圍。 採用這些建議，並建立與提取要求分開的新工作專案和功能分支，以進行這些變更。
透過設置政策來保護分支
存放庫中有一些重要分支，小組會依賴這些分支一律處於良好狀態，例如 main 分支。 團隊可以要求拉取請求，才能使用 GitHub 和 Azure DevOps 等平台在這些分支上進行任何變更。 將變更直接推送至受保護分支的開發人員將會拒絕其推送。
將其他條件新增至提取要求，以在關鍵分支中強制執行更高層級的程式碼品質。 合併程式碼的乾淨建置和多個檢閱者的核准是一些經常用來保護關鍵分支的額外要求。
瞭解詳情
GitHub 有大量關於如何使用 拉取請求對你的工作提出更改的文件。
深入瞭解如何在 程式碼檢閱中提供良好的意見反應 ，以及 使用提取要求範本為檢閱者提供指引。 Azure DevOps 也提供 豐富的提取要求體驗 ，易於使用，並視需要進行調整。