拉取请求就像存储库的生命血液。它们能使一切保持健康和运转本页详细介绍了如何创建完整且易于审核的 PR，从而提高 PR 被合并的可能性。
为了确保制作出色的公关效果，您可以采取以下措施。
多多沟通交流
在开始编写代码之前，最好与核心团队沟通，让他们知道您感兴趣的内容。
如果发现您感兴趣的问题，请对该问题发表评论，表明您将着手解决该问题。这样可以确保没有多人同时处理同一任务我们会有团队成员回复，确认这是您本人所为。
如果您的想法无法涵盖在问题范围内，请在开始着手处理前撰写一条信息。 这样，团队就有机会在开始构建之前讨论如何以最佳方式构建变更，从长远来看，这可以节省您的工作。
进行设置
如果这是您首次为 Blockly 或 blockly-samples 做贡献，请从开发设置页面开始。
尽量减小
请始终尽量保持小幅改动并重点突出。我们更希望审核多个较小的 PR，而不是审核一个大型 PR。下面是一些不错的经验法则：
- 解决一个问题。不要试图同时解决多个问题。
- 限制范围。通常，PR 应该不到 8 小时（具体取决于您对代码库的熟悉程度）。
- 使用提交内容。如果您的 PR 有点大，请使用 Git 提交将更改拆分为多个逻辑组。
保持清洁
为何要关注代码样式？我们长期使用它，而且一致的风格可使维护变得更简单。样式是指为变量命名的方式，还包括如何设计代码结构以及编写注释等。我们会尽可能使用 eslint 等工具自动进行样式检查。
除了 eslint 之外，还请遵循以下指南：
测试您的更改
在发布 PR 之前，您应该始终测试您的更改是否有效，这样您以后就不必回头去解决问题。以下是一些关于测试不同类别项目的想法：
- 对于插件：编写自动化 Mocha 测试来涵盖您的更改。
- 示例：手动测试所有所演示的功能。
- 对于 Codelab：在干净的环境中运行整个教程，并测试您提供的所有示例代码。
多多沟通交流
这是创建 PR 的最后一个部分，也是最重要的部分：撰写摘要。
撰写精彩的 PR 摘要有助于其他开发者审核您的更改，从而提高更改被接受的几率！
您的摘要应包含以下信息：
- 您的 PR 与什么问题相关。
- 公关带来的改变。
- 您测试更改的方式。
- 您希望审核人员审查的任何信息。
- 您认为审核者需要的任何其他信息。
如果您在创建请求时遵循 PR 模板，则应该没有问题。请记得尽可能简洁和完整。
祝您编码顺利！