版本

提交 Pull Request

如果您想要貢獻 ESLint 程式碼庫，請使用 GitHub Pull Request。這是我們評估您的程式碼並將其合併到程式碼庫中的最快方式。請不要提交帶有程式碼片段的 issue。這樣做意味著我們需要手動合併變更並更新任何適當的測試。這會降低您的程式碼及時被納入的可能性。請使用 Pull Request。

開始使用

如果您想處理 Pull Request，而且您從未提交過程式碼，請按照以下步驟操作

  1. 設定開發環境。
  2. 如果您想實作重大變更或核心變更，請確保有一個 issue 描述您正在做的事情，並且該 issue 已被接受。您可以建立新的 issue 或只是表明您正在處理現有的 issue。錯誤修復、文件變更和其他 Pull Request 不需要 issue。

完成後，您就可以開始處理程式碼了。

處理程式碼

提交 Pull Request 的過程相當簡單，而且通常每次都遵循相同的模式

  1. 建立新分支
  2. 進行變更
  3. 變基至上游
  4. 執行測試
  5. 再次檢查您的提交
  6. 推送您的變更
  7. 提交 Pull Request

以下為每個步驟的詳細資訊。

步驟 1：建立新分支

發送 Pull Request 的第一步是在您的 ESLint fork 中建立新的分支。為分支指定一個描述性的名稱，描述您正在修復的內容，例如

git checkout -b issue1234

您應該在此分支中完成針對 issue 的所有開發。

注意： 不要將多個 issue 的修復合併到一個分支中。針對您正在處理的每個 issue 使用單獨的分支。

步驟 2：進行變更

對程式碼和測試進行變更，並遵循程式碼慣例。完成後，將變更提交到您的分支

git add -A
git commit

所有 ESLint 專案都遵循Conventional Commits 作為我們的提交訊息。（注意：我們不支援訊息中的可選範圍。）以下是一個提交訊息範例

tag: Short description of what you did

Longer description here if necessary

Fixes #1234

提交訊息的第一行（摘要）必須具有特定格式。此格式會由我們的建置工具檢查。儘管提交訊息不會被直接檢查，但它將用於產生 Pull Request 的標題，該標題會在提交 Pull Request 時被檢查。

tag 是以下其中之一

  • fix - 用於錯誤修復。
  • feat - 用於向後相容的增強功能或用於新增回報問題的規則變更。
  • fix! - 用於向後不相容的錯誤修復。
  • feat! - 用於向後不相容的增強功能或功能。
  • docs - 僅限文件變更。
  • chore - 用於非使用者面向的變更。
  • build - 僅限建置過程變更。
  • refactor - 不影響 API 或使用者體驗的變更。
  • test - 僅限測試檔案變更。
  • ci - 我們的 CI 設定檔和腳本變更。
  • perf - 提高效能的程式碼變更。

使用您正在處理的 issue 的標籤來確定最佳標籤。

訊息摘要應為對變更的一句話描述，且長度必須為 72 個字元或更短。如果 Pull Request 解決了一個 issue，則應在提交訊息的主體中以 Fixes #1234 的格式提及 issue 編號。如果提交未完全修復該 issue，則使用 Refs #1234 而不是 Fixes #1234。

以下是一些好的提交訊息摘要範例

build: Update Travis to only test Node 0.10
fix: Semi rule incorrectly flagging extra semicolon
chore: Upgrade Esprima to 1.2, switch to using comment attachment

步驟 3：變基至上游

在您發送 Pull Request 之前，請務必變基至上游來源。這可確保您的程式碼在最新的可用程式碼上執行。

git fetch upstream
git rebase upstream/main

步驟 4：執行測試

變基後，請務必再次執行所有測試，以確保沒有任何東西損壞

npm test

如果有任何測試失敗，請更新您的程式碼，直到所有測試都通過。

步驟 5：再次檢查您的提交

您的程式碼已準備就緒，現在是再次檢查您的提交以確保其符合我們的慣例的好時機。以下是要檢查的事項

  • 提交訊息的格式正確。
  • 變更不會造成任何功能上的倒退。請務必執行 npm test 以在提交 Pull Request 之前驗證您的變更。
  • 針對不相關的變更建立單獨的 Pull Request。包含多個不相關變更的大型 Pull Request 可能會在未合併的情況下關閉。
  • 所有變更都必須附帶測試，即使您正在處理的功能以前沒有測試也是如此。
  • 所有使用者面向的變更都必須附帶適當的文件。
  • 遵循程式碼慣例。

步驟 6：推送您的變更

接下來，將您的變更推送至您的複製版本

git push origin issue1234

如果因為某些參考資料已過時而無法推送，請改為強制推送

git push -f origin issue1234

步驟 7：發送 Pull Request

現在您可以發送 Pull Request 了。前往您的 ESLint fork，然後按照 GitHub 文件了解如何發送 Pull Request。

為了向 ESLint 專案提交程式碼或文件，您會在發送第一個 Pull Request 時被要求簽署我們的 CLA。（在 https://cla.openjsf.org/ 閱讀更多關於 OpenJS Foundation CLA 流程的資訊。）

Pull Request 標題會從第一個提交的摘要自動產生，但可以在提交 Pull Request 之前編輯。

Pull Request 的描述應解釋您做了什麼以及如何看到其效果。

合併 Pull Request 後，其提交將會被壓縮成單一提交。壓縮的提交訊息的第一行將包含 Pull Request 的標題和 Pull Request 編號。Pull Request 標題格式非常重要，因為標題會用於為每個版本建立變更記錄。標籤和 issue 編號有助於建立更一致且更有用的變更記錄。

後續處理

發送 Pull Request 後，是時候讓團隊審閱它了。因此，請務必

  1. 監控您的 Pull Request 的 GitHub Actions CI 建置狀態。如果失敗，請調查原因。我們無法合併任何由於任何原因而導致 CI 建置失敗的 Pull Request。
  2. 回應團隊成員在 Pull Request 上留下的評論。請記住，我們希望幫助您將程式碼納入，因此請接受我們的意見回饋。
  3. 我們可能會要求您進行變更、變基或壓縮您的提交。

更新 Pull Request 標題

如果您的 Pull Request 標題格式不正確，您會被要求更新它。您可以使用 GitHub 使用者介面執行此操作。

更新程式碼

如果我們要求您進行程式碼變更，則無需關閉 Pull Request 並建立新的 Pull Request。只需返回您的 fork 上的分支並進行變更即可。然後，當您準備就緒時，您可以將變更新增至分支中

git add -A
git commit
git push origin issue1234

更新程式碼時，通常最好將其他提交新增至您的分支，而不是修改原始提交，因為審閱者可以輕鬆判斷哪些變更是為了回應特定審閱而進行的。當我們合併 Pull Request 時，我們會將您分支中的所有提交壓縮到 main 分支上的單一提交中。

後續提交中的提交訊息不需要任何特定格式，因為這些提交不會顯示在變更記錄中。

變基

如果您的程式碼已過時，我們可能會要求您變基。這表示我們希望您將變更套用在最新的上游程式碼之上。請確保您已設定開發環境，然後您可以使用以下命令進行變基

git fetch upstream
git rebase upstream/main

您可能會發現在嘗試變基時出現合併衝突。請解決衝突，然後對您的分支進行強制推送

git push origin issue1234 -f
編輯此頁面
© OpenJS Foundation 和 ESLint 貢獻者，www.openjsf.org。內容在 MIT 授權下授權。
變更語言