Pull Requests (拉取请求)
设置本地开发环境
步骤 1: Fork (复刻)
在 GitHub 上复刻 该项目，并将你的复刻版克隆到本地。
$ git clone git@github.com:username/electron.git
$ cd electron
$ git remote add upstream https://github.com/electron/electron.git
$ git fetch upstream
步骤 2: Build (构建)
根据你的操作系统，构建步骤和依赖项会略有不同。请参阅以下关于在本地构建 Electron 的详细指南：
在本地构建项目后，你就可以开始进行更改了！
步骤 3: Branch (创建分支)
为了保持你的开发环境井井有条，请创建本地分支来存放你的工作。这些分支应该直接从 main 分支创建。
$ git checkout -b my-branch -t upstream/main
进行更改
步骤 4: Code (编写代码)
大多数针对 electron/electron 仓库打开的 pull request 都包含对以下部分的更改：shell/ 文件夹中的 C/C++ 代码、lib/ 文件夹中的 JavaScript 代码、docs/api/ 中的文档或 spec/ 文件夹中的测试。
请务必不时地运行 npm run lint 来检查代码更改，以确保它们符合项目的代码风格。
有关修改项目不同部分代码的最佳实践，请参阅 coding style (代码风格)。
步骤 5: Commit (提交)
建议将你的更改逻辑性地分组到单独的提交中。许多贡献者发现将更改拆分成多个提交更容易评审。Pull Request 中的提交数量没有限制。
$ git add my/changed/files
$ git commit
请注意，多个提交在合并时会被压缩。
Commit signing (提交签名)
electron/electron 仓库强制要求所有传入的 PR 都进行 commit signatures (提交签名)。要签名你的提交，请参阅 GitHub 关于 Telling Git about your signing key (告知 Git 关于你的签名密钥) 的文档。
Commit Message (提交信息) 指南
一个好的提交信息应该描述了什么改变以及为什么。Electron 项目使用 semantic commit messages (语义化提交信息) 来简化发布流程。
在 Pull Request 可以被合并之前，它必须有一个带有语义化前缀的 Pull Request 标题。
带有语义化前缀的提交信息的示例
fix: 修复了未正确处理 prevent_default 的情况，即使默认行为未被阻止feat: 添加了 app.isPackaged() 方法docs: app.isDefaultProtocolClient 现在在 Linux 上可用
常用前缀
- fix: 错误修复
- feat: 新功能
- docs: 文档更改
- test: 添加缺失的测试或修正现有测试
- build: 影响构建系统的更改
- ci: 对 CI 配置文件和脚本的更改
- perf: 改进性能的代码更改
- refactor: 既不修复错误也不添加功能的代码更改
- style: 不影响代码含义的更改（代码风格检查）
撰写提交信息时需要注意的其他事项
- 第一行应该
- 包含对更改的简短描述（最好不超过 50 个字符，最多不超过 72 个字符）
- 除了专有名词、缩略词和指代代码的词（如函数/变量名）之外，全部使用小写字母。
- 第二行留空。
- 将所有其他行限制在 72 个字符以内。
破坏性变更
在提交消息的可选正文或脚注部分以 BREAKING CHANGE: 开头的提交引入了破坏性的 API 更改（对应于语义化版本中的 Major 版本）。破坏性更改可以是任何类型的提交的一部分，例如，fix:、feat: 和 chore: 类型都是有效的，以及任何其他类型。
有关更多详细信息，请参阅 conventionalcommits.org。
步骤 6: Rebase (变基)
提交更改后，最好使用 git rebase（而不是 git merge）来同步你与主仓库的工作。
$ git fetch upstream
$ git rebase upstream/main
这确保了你的工作分支包含来自 electron/electron main 的最新更改。
步骤 7: Test (测试)
错误修复和新功能应始终附带测试。已提供 testing guide (测试指南) 以简化此过程。查看其他测试的结构也可以提供帮助。
在提交 Pull Request 之前，请务必运行完整的测试套件。要运行测试：
$ npm run test
确保 linter 没有报告任何问题，并且所有测试都通过。请勿提交任何一项检查失败的补丁。
如果你正在更新测试并且想运行单个 spec 来检查它：
$ npm run test -match=menu
上面的命令只会运行与 menu 匹配的 spec 模块，这对于那些正在处理测试但否则将落在测试周期末尾的开发者很有用。
步骤 8: Push (推送)
一旦你的提交准备就绪——通过了测试和 linter 检查——就可以通过将你的工作分支推送到 GitHub 上的 fork 来开始打开 Pull Request 的过程。
$ git push origin my-branch
步骤 9: 打开 Pull Request
在 GitHub 中，打开一个新的 Pull Request 会显示一个需要填写的模板。你可以在 这里 找到它。
如果你没有充分填写此模板，你的 PR 可能会被延迟合并，因为维护者需要更多信息或澄清模糊之处。
步骤 10: 讨论和更新
你可能会收到关于你的 Pull Request 的反馈或更改请求。这是提交过程中很重要的一部分，所以不要气馁！一些贡献者可能会立即签署 Pull Request。其他人可能会有详细的评论或反馈。这是评估更改是否正确和必要的必要过程。
要对现有的 Pull Request 进行更改，请在你的本地分支上进行更改，然后添加一个包含这些更改的新提交，并将其推送到你的 fork。GitHub 会自动更新 Pull Request。
$ git add my/changed/files
$ git commit
$ git push origin my-branch
有许多使用 git rebase 管理提交的更高级机制，但它们超出了本指南的范围。
如果你正在等待某个问题的答复，请随时在 Pull Request 中发表评论来提醒审阅者。如果你遇到不熟悉的词语或缩略语，请参考此 glossary (术语表)。
Approval and Request Changes Workflow (批准和请求更改工作流)
所有 Pull Request 都需要你修改区域的 Code Owner (代码所有者) 批准才能合并。维护者在审阅 Pull Request 时可能会请求更改。这些更改可能很小，例如修复一个拼写错误，也可能涉及实质性的修改。这些请求旨在提供帮助，但有时可能会显得生硬或无益，尤其是当它们不包含具体的建议时，说明如何进行更改。
尽量不要气馁。如果你觉得审阅不公平，请说出来或寻求其他项目贡献者的意见。很多时候，这种评论是由于审阅者没有花足够的时间进行审阅而产生的，并非恶意。这样的困难通常可以通过一点耐心来解决。话虽如此，审阅者也应该提供有用的反馈。
步骤 11: Landing (合并)
要合并，Pull Request 需要至少一名 Electron 代码所有者进行审阅和批准，并通过 CI。之后，如果没有其他贡献者的反对，Pull Request 就可以合并了。
恭喜你，感谢你的贡献！
Continuous Integration Testing (持续集成测试)
所有 Pull Request 都会在持续集成 (CI) 系统上进行测试，以确认它们在 Electron 支持的平台上能够正常工作。
理想情况下，Pull Request 在所有 CI 平台上都能通过（“变为绿色”）。这意味着所有测试都通过，并且没有 linting 错误。然而，CI 基础架构本身在特定平台上失败，或者所谓的“flaky”测试失败（“变为红色”）的情况并不少见。每个 CI 失败都必须手动检查以确定原因。
CI 会在你打开 Pull Request 时自动启动，但只有核心维护者才能重新启动 CI。如果你认为 CI 报告了误报，请请求维护者重新运行测试。