提交 Pull Request

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

开始使用

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

设置开发环境。
如果您想实现一个破坏性更改或对核心进行更改，请确保存在一个描述您正在做什么的问题，并且该问题已被接受。您可以创建一个新问题，或者只是表明您正在处理现有问题。错误修复、文档更改和其他 pull request 不需要问题。

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

使用代码

提交 pull request 的过程非常简单，并且通常每次都遵循相同的模式

创建一个新分支.
进行更改.
变基到上游.
运行测试.
仔细检查您的提交.
推送您的更改.
提交 pull request.

有关每个步骤的详细信息，请参见下文。

步骤 1：创建一个新分支

发送 pull request 的第一步是在您的 ESLint 分支中创建一个新分支。给分支一个描述性的名称，描述您正在修复的内容，例如

git checkout -b issue1234
1

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

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

步骤 2：进行更改

按照代码约定对代码和测试进行更改。完成后，将更改提交到您的分支

git add -A
git commit
1
2

所有 ESLint 项目都遵循Conventional Commits来编写我们的提交消息。（注意：我们不支持消息中的可选范围。）这是一个提交消息示例

tag: Short description of what you did

Longer description here if necessary

Fixes #1234
1
2
3
4
5

提交消息的第一行（摘要）必须具有特定格式。此格式由我们的构建工具检查。尽管提交消息不会被直接检查，但它将用于生成 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
1
2
3

步骤 3：变基到上游

在您发送 pull request 之前，请务必变基到上游源。这确保您的代码在最新的可用代码上运行。

git fetch upstream
git rebase upstream/main
1
2

步骤 4：运行测试

变基后，请务必再次运行所有测试，以确保没有任何问题

npm test
1

如果存在任何失败的测试，请更新您的代码，直到所有测试都通过。

步骤 5：仔细检查您的提交

在您的代码准备就绪后，现在是仔细检查您的提交以确保其符合我们的约定的好时机。以下是需要检查的事项

提交消息的格式正确。
更改不会引入功能倒退。请务必运行 npm test 以在提交 pull request 之前验证您的更改。
为不相关的更改创建单独的 pull request。包含多个不相关更改的大型 pull request 可能会被关闭而不合并。
所有更改都必须附带测试，即使您正在处理的功能以前没有测试。
所有面向用户的更改都必须附带适当的文档。
遵循代码约定。

步骤 6：推送您的更改

接下来，将您的更改推送到您的克隆

git push origin issue1234
1

如果您由于某些引用过旧而无法推送，请改为强制推送

git push -f origin issue1234
1

步骤 7：发送 pull request

现在您可以发送 pull request 了。转到您的 ESLint 分支，然后按照关于如何发送 pull request 的 GitHub 文档进行操作。

为了向 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 发送，就该团队进行审查了。因此，请确保

监控您的 pull request 的 GitHub Actions CI 构建状态。如果失败，请调查原因。我们无法合并因任何原因导致 CI 构建失败的 pull request。
回复团队成员在 pull request 上留下的评论。请记住，我们希望帮助您提交您的代码，因此请接受我们的反馈。
我们可能会要求您进行更改、变基或压缩您的提交。

更新 Pull Request 标题

如果您的 pull request 标题格式不正确，您将被要求更新它。您可以通过 GitHub 用户界面执行此操作。

更新代码

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

git add -A
git commit
git push origin issue1234
1
2
3

在更新代码时，通常最好在您的分支中添加额外的提交，而不是修改原始提交，因为审查者可以很容易地判断哪些更改是响应特定审查而进行的。当我们合并 pull request 时，我们将把您分支中的所有提交压缩成 main 分支上的单个提交。

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

变基

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

git fetch upstream
git rebase upstream/main
1
2

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

git push origin issue1234 -f
1

编辑此页面