拉取请求就像是存储库的生命线。它们让一切都保持健康，并持续运动。本页面详细介绍了如何创建完整且易于审核的 PR，从而使您的 PR 合并的可能性更高。
您可以采取以下步骤，确保您尽可能获得最佳的 PR 结果。
在您开始编写代码之前，与核心团队进行沟通很有帮助，这样他们就会知道您对什么感兴趣。
如果您对某个 issue 感兴趣，请在 issue 中评论说明你要开始解决该 issue。这样可以确保不会有多人同时处理同一件事。团队成员会进行回复，以确认这是否是您本人所为。
如果您有想法未包含在 issue 中，请在开始工作之前写一个。这样，该团队就有机会在开始构建之前讨论如何最有效地构建更改，从长远来看可以节省工作量。
如果这是您首次为 Blockly 或 blockly-samples 贡献代码，请从 开发设置 页面开始。
请尽量尝试保持较小的更改并保持专注。我们更倾向于审核多个较小的 PR，而不是审核一个大型 PR。一些好的经验法则：
- 修正一个问题。 请勿尝试同时解决多个 issue。
- 限制范围。 通常，PR 应该不到 8 小时（具体取决于您对代码库的熟悉程度）。
- 使用提交内容。 如果 PR 感觉有点大，请使用 Git 提交功能将更改拆分成逻辑组。
为何关注代码风格？从长远来看，这是我们的一贯目标，一致的风格可以简化维护。风格涉及如何命名变量，但也介绍了如何构建代码、如何编写注释等。我们会尽可能使用 eslint 等工具自动进行样式检查。
除了 eslint，请遵循以下指南：
在发布 PR 之前，您应始终测试更改是否有效，这样您便无需返工并事后解决问题。以下是测试不同类别项目的一些方法：
- 对于 插件：编写覆盖更改的自动化 Mocha 测试。
- 示例：手动测试所有已演示的功能。
- 对于 Codelab：在整洁的环境中运行整个教程，并测试您提供的任何示例代码。
这是创建 PR 的最后一个环节，可以说是最重要的环节：撰写摘要。
撰写优质的 PR 摘要有助于其他开发者查看您的更改，提高其被接受的可能性！
摘要应包含以下内容：
- 您的 PR 相关 issue。
- 您的 PR 添加哪些更改。
- 您测试更改的方式。
- 任何您想要评审者仔细审查的内容。
- 您认为评审人员需要的任何其他信息。
如果您在创建请求时遵循 PR 模板，应该可以顺利完成。请记得尽可能简洁且完整。
编码愉快！