管理 Pull Request
審查 pull request 可能會花費相當多的時間。在某些情況下，審查所需的時間可能比某人編寫和提交變更所需的時間還要多！因此，有必要做一些初步工作，以確保每個 pull request 都處於良好的審查狀態。
一個 pull request 應包含三個主要部分
- 摘要。這有助於我們理解變更背後的動機。
- 變更日誌。這有助於我們編寫發行說明。它也可以作為您的變更的簡要摘要。
- 測試計畫。這可能是您的 pull request 中最重要的一部分。測試計畫應為可重現的逐步指南，以便審查者可以驗證您的變更是否如預期般運作。為使用者可見的變更附上螢幕截圖或影片也是一個好主意。
任何 pull request 都可能需要更深入地了解您可能不熟悉的 React Native 的某些領域。即使您覺得自己不是審查 pull request 的合適人選，您仍然可以透過新增標籤或要求作者提供更多資訊來提供幫助。
審查 PR
Pull Request 需要在使用 GitHub 的審查功能進行審查和批准後才能合併。雖然任何人都有能力審查和批准 pull request，但我們通常只在收到來自貢獻者之一的批准時，才認為 pull request 已準備好合併。
因此，您找到了一個您有信心審查的 pull request。請使用 GitHub 審查功能，並清楚且禮貌地溝通任何建議的變更。
考慮從已被標記為缺少變更日誌或測試計畫的 pull request 開始。
- 看起來缺少變更日誌的 PR - 看一看，看看您是否可以透過編輯 PR 自己新增變更日誌。完成後，移除「Missing Changelog」標籤。
- 缺少測試計畫的 PR - 開啟 pull request 並尋找測試計畫。如果測試計畫看起來足夠，請移除「Missing Test Plan」標籤。如果沒有測試計畫，或看起來不完整，請新增評論，禮貌地要求作者考慮新增測試計畫。
pull request 必須通過所有測試才能合併。它們在 main 和 pull request 上的每次提交時都會執行。幫助我們讓 pull request 準備好進行審查的一個快速方法是搜尋未通過預提交測試的 pull request，並判斷它們是否需要修訂。失敗的測試通常列在執行緒的底部附近，在「Some checks were not successful.」下方。
- 快速瀏覽一下 main 上的最新測試執行。
main是綠色的嗎？如果是，- 看起來失敗可能與此 pull request 中的變更有關嗎？請作者調查。
- 即使
main目前是綠色的，也要考慮 pull request 中的提交可能是基於main已損壞的時間點的提交。如果您認為可能是這種情況，請要求作者將其變更重新基於main之上，以便引入在他們開始處理 pull request 後可能已落地的任何修復。
- 如果
main似乎已損壞，請尋找任何標記為「CI Test Failure」的 issue。- 如果您發現與
main上的失敗相關的 issue，請回到 pull request 並感謝作者提出這些變更，並讓他們知道測試失敗可能與他們的特定變更無關（不要忘記連結回 CI Test Failure issue，因為這將有助於作者知道他們何時可以再次嘗試執行測試）。 - 如果您找不到描述您在
main上觀察到的問題的現有 CI Test Failure issue，請提交新的 issue 並使用「CI Test Failure」標籤，讓其他人知道main已損壞（請參閱此 issue 作為範例）。
- 如果您發現與
我們如何優先處理 PR
Meta 的 React Native 團隊成員旨在快速審查 pull request，大多數 PR 將在一週內得到回覆。
PR 如何合併？
React Native GitHub 儲存庫實際上是 Meta 其中一個 monorepo 中子目錄的鏡像。因此，pull request 並非以傳統意義上的方式合併。相反，它們需要作為 「diff」 匯入到 Meta 的內部程式碼審查系統中。
匯入後，變更將經過一連串的測試。其中一些測試是 land-blocking，表示它們需要成功才能合併 diff 的內容。Meta 始終從 main 執行 React Native，並且某些變更可能需要 Facebook 員工將內部變更附加到您的 pull request，然後才能合併。例如，如果您重新命名模組名稱，則必須在同一個變更中更新所有 Facebook 內部呼叫點才能合併它。如果 diff 成功落地，則變更最終將由 ShipIt 作為單次提交同步回 GitHub。
Meta 員工正在使用 GitHub 的自訂瀏覽器擴充功能，可以透過兩種方式匯入 pull request：pull request 可以「landed to fbsource」，表示它將被匯入，並且產生的 diff 將自動批准，並且在沒有任何失敗的情況下，變更最終將同步回 main。pull request 也可以「imported to Phabricator」，表示變更將被複製到內部 diff，這需要進一步的審查和批准才能落地。
機器人
當您審查和處理 pull request 時，您可能會遇到一些 GitHub 機器人帳戶留下的評論。這些機器人已設定為協助 pull request 審查流程。請參閱機器人參考以了解更多資訊。
Pull Request 標籤
Merged：應用於已關閉的 PR，以指示其變更已併入核心儲存庫。此標籤是必要的，因為 pull request 並非直接在 GitHub 上合併。相反，包含 PR 變更的修補程式會被匯入並排隊等待程式碼審查。一旦獲得批准，將這些變更應用於 Meta 內部 monorepository 之上的結果將作為新的提交同步到 GitHub。GitHub 不會將該提交歸因於原始 PR，因此需要一個標籤來傳達 PR 的真實狀態。Blocked on FB：PR 已匯入，但變更尚未應用。