版本

提交 Pull Request

如果您想为 ESLint 代码库做贡献，请使用 GitHub Pull Request。这是我们评估您的代码并将其合并到代码库中的最快方式。请不要在问题中提交代码片段。这样做意味着我们需要手动合并更改并更新所有相关的测试。这会降低您的代码及时包含的可能性。请使用 Pull Request。

入门

如果您想处理 Pull Request 并且以前从未提交过代码，请按照以下步骤操作

  1. 设置一个开发环境。
  2. 如果您想实施重大更改或对核心进行更改，请确保有一个问题描述您正在做的事情，并且该问题已获接受。您可以创建新问题或仅仅表明您正在处理现有问题。错误修复、文档更改和其他 Pull Request 不需要问题。

之后，您就可以开始编写代码了。

使用代码

提交 Pull Request 的过程相当简单，通常每次都遵循相同的模式

  1. 创建一个新分支
  2. 进行您的更改
  3. 重新定位到上游
  4. 运行测试
  5. 仔细检查您的提交
  6. 推送您的更改
  7. 提交 Pull Request

有关每个步骤的详细信息，请参阅以下内容。

步骤 1：创建一个新分支

发送 Pull Request 的第一步是在您的 ESLint 分支中创建一个新分支。为分支指定一个描述性的名称，描述您要修复的内容，例如

git checkout -b issue1234

您应该在这个分支中完成所有与问题相关的开发工作。

注意：不要将多个问题的修复合并到一个分支中。为每个要处理的问题使用单独的分支。

步骤 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 - 提高性能的代码更改。

使用您正在处理的问题的标签 来确定最佳标签。

消息摘要应为对更改的单句描述，且长度不超过 72 个字符。如果 Pull Request 解决了一个问题，则应在提交信息正文中以 Fixes #1234 的格式提及问题编号。如果提交未完全解决问题，则使用 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 分支，然后按照GitHub 文档 中的说明发送 Pull Request。

为了将代码或文档提交到 ESLint 项目，您将在发送第一个 Pull Request 时被要求签署我们的 CLA。（有关 OpenJS Foundation CLA 过程的更多信息，请访问https://cla.openjsf.org/。）

Pull Request 标题会根据第一个提交的摘要自动生成，但可以在提交 Pull Request 之前进行编辑。

Pull Request 的描述应说明您所做的事情以及如何看到其效果。

合并 Pull Request 后，其提交将被压缩成一个单独的提交。压缩提交信息的首页将包含 Pull Request 的标题和 Pull Request 编号。Pull Request 标题格式非常重要，因为标题用于为每个版本创建变更日志。标签和问题编号有助于创建更一致、更有用的变更日志。

后续

发送 Pull Request 后，团队将对其进行审查。因此，请务必

  1. 监控您的 Pull Request 的 GitHub Actions CI 构建状态。如果失败，请调查原因。我们无法合并任何因任何原因而导致 CI 构建失败的 Pull Request。
  2. 回复团队成员对 Pull Request 所做的评论。请记住，我们希望帮助您发布代码，因此请接受我们的反馈意见。
  3. 我们可能会要求您进行更改、重新定位或压缩提交。

更新 Pull Request 标题

如果您的 Pull Request 标题格式不正确，您将被要求对其进行更新。您可以通过 GitHub 用户界面进行操作。

更新代码

如果我们要求您进行代码更改，则无需关闭 Pull Request 并创建一个新的 Pull Request。只需返回到您分支上的分支并进行更改。然后，准备就绪后，您就可以将更改添加到分支中

git add -A
git commit
git push origin issue1234

更新代码时，通常最好在分支中添加额外的提交，而不是修改原始提交，因为评审者可以轻松地识别哪些更改是针对特定评审进行的。当我们合并拉取请求时，我们会将您分支中的所有提交压缩成main分支上的单个提交。

后续提交中的提交消息不需要任何特定格式，因为这些提交不会显示在更改日志中。

重新定位

如果您的代码已过期，我们可能会要求您进行变基。这意味着我们希望您将更改应用到最新的上游代码之上。请确保您已设置了开发环境，然后可以使用以下命令进行变基

git fetch upstream
git rebase upstream/main

您可能会发现，当您尝试进行变基时会发生合并冲突。请解决冲突，然后对您的分支进行强制推送

git push origin issue1234 -f
编辑此页面
© OpenJS 基金会和 ESLint 贡献者，www.openjsf.org。内容根据 MIT 许可 授权。
更改语言