審閱 Pull Requests

Pull requests 會頻繁提交，並且是我們與社群互動的最佳機會。因此，在合併之前，Pull requests 必須經過良好的審閱，並且 Pull requests 上的互動必須是正向的。

誰可以審閱 Pull Requests？

任何人，包括團隊成員和公眾，都可以在 Pull requests 上留下註解。

當 Pull Request 開啟時，機器人會檢查以下內容

機器人會添加一個註解，指定它發現的問題。在這些問題解決之前，您不需要進一步查看 Pull Request（不需要在 Pull Request 上留言，要求提交者執行機器人要求的動作 - 這就是我們有機器人的原因！）。

一旦機器人檢查通過，您需要檢查以下內容

再次檢查 Pull Request 標題是否基於問題（或者，如果沒有參考任何問題，則基於所述的問題）正確。
如果 Pull Request 對核心進行了變更，請確保存在一個問題，並且 Pull Request 在提交訊息中參考了該問題。
程式碼是否遵循我們的慣例（包括標頭註解、JSDoc 註解等）？如果沒有，請留下回饋並參考程式碼慣例文件。
對於程式碼變更
- 是否有驗證變更的測試？如果沒有，請要求提供。
- 此變更是否需要文件？如果是，請要求提交者新增必要的文件。
是否有任何自動測試錯誤？如果是，請要求提交者檢查它們。
如果您已審閱 Pull Request，並且沒有未解決的問題，請留下註解「LGTM」以表示您的批准。如果您希望其他人驗證此變更，請註解「LGTM 但希望其他人驗證。」

注意： 如果您是團隊成員，並且在 Pull Request 上留下了註解，請追蹤以驗證您的註解是否已解決。

任何提交者、審閱者或 TSC 成員都可以批准 Pull Request，但是合併所需的批准會因 Pull Request 的類型而異。

合併非破壞性變更需要一位提交者的批准，這些變更包括

對於非破壞性功能，Pull requests 需要一位審閱者或 TSC 成員的批准，以及任何其他團隊成員的一項額外批准。

對於破壞性變更，Pull requests 需要兩位 TSC 成員的批准。

當建立 Pull Request 時，無論是團隊成員還是外部貢獻者，它都會自動放置在分流板的「需要分流」欄中。Pull Request 應保留在該欄中，直到團隊成員開始審閱它。

如果 Pull Request 沒有相關的問題，則應將其通過正常的問題分流流程，以標記為已接受。一旦接受，請將 Pull Request 移動到「實作中」欄。

如果 Pull Request 有相關的問題，則

一旦 Pull Request 獲得一項批准，可能會發生以下三件事之一

當 Pull Request 獲得第二次批准時，如果 100% 準備就緒，則應將其合併；如果存在任何應在下次發佈之前審閱的未解決問題，則應將其移動到「合併候選」欄。

TSC 成員、審閱者、提交者和網站團隊成員可以合併 Pull Request，具體取決於 Pull Request 的內容，一旦它收到所需的批准。

網站團隊成員可以在 eslint.org 儲存庫中合併 Pull Request，如果它是

我們使用「合併」按鈕將請求合併到儲存庫中。在合併 Pull Request 之前，請驗證

合併之前，請務必向提交者表示感謝，尤其是如果他們為 Pull Request 付出了很多努力。

團隊成員可以立即合併 Pull Request，如果它

否則，團隊成員應在合併 Pull Request 之前觀察等待期

等待期可確保其他團隊成員有機會在合併之前審閱 Pull Request。

注意： 除非您收到所需的批准，否則不應合併您的 Pull Request。

在以下幾種情況下，適合在不合併的情況下關閉 Pull Request

在任何這些情況下，請務必留下註解，說明關閉 Pull Request 的原因。

如果 Pull Request 已 17 天未更新

由於 17 天沒有活動，因此關閉。如果您仍然有興趣提交此程式碼，請隨時重新提交。

如果 Pull Request 提交者不願意遵循專案指南。

很遺憾，我們無法接受不遵循我們指南的 Pull Request。我現在要關閉這個 Pull Request，但是如果您想重新提交並遵循我們的指南，我們將很樂意審閱。

編輯此頁面