拉取请求就像代码库的生命之源。它们可以确保一切正常运行。本页详细介绍了如何创建完整且易于审核的 PR，以提高 PR 合并的可能性。
以下是确保您能制作出最佳公共关系内容的步骤。
沟通交流
在开始编写代码之前，与核心团队沟通会很有帮助，这样他们就能了解您感兴趣的领域。
如果您对某个问题感兴趣，请在该问题上发表评论，说明您将开始着手解决该问题。这样可以确保不会有多个人同时处理同一事项。我们的团队成员会回复您，确认该设备是否归您所有。
如果您有想法，但未在问题中涵盖，请先撰写一份提案，然后再开始工作。这样一来，团队就有机会在您开始构建之前讨论如何最好地构建更改，从长远来看，这可以为您节省工作量。
进行设置
如果这是您首次为 Blockly 或 blockly-samples 做出贡献，请先参阅开发设置页面。
保持小巧
请始终尽量缩小更改范围，并确保更改有针对性。我们更愿意审核多个较小的 PR，而不是审核一个巨大的 PR。以下是一些实用经验法则：
- 解决一个问题。请勿尝试同时解决多个问题。
- 限制范围。通常，PR 应该需要不到 8 小时（具体取决于您对代码库的熟悉程度）。
- 使用提交。如果您的 PR 有点大，请使用 git 提交将更改拆分为逻辑组。
保持清洁
为什么要关心代码样式？我们会长期坚持下去，而一致的样式有助于简化维护。风格不仅仅是指变量命名方式，还涵盖了代码结构、注释编写等方面。我们会尽可能使用 eslint 等工具来自动执行样式检查。
除了 eslint 之外，请遵循以下指南：
测试更改
在提交 PR 之前，您应始终测试更改是否有效，以免日后不得不返回并进行修复。以下是一些关于测试不同类别项目的建议：
- 对于插件：编写涵盖所做更改的自动化 mocha 测试。
- 示例：手动测试您演示的所有功能。
- 对于 codelabs：在干净的环境中完整运行整个教程，并测试您提供的任何示例代码。
沟通交流
这是创建 PR 的最后一步，也是最重要的一步：撰写摘要。
撰写出色的 PR 摘要有助于其他开发者审核您的更改，从而提高更改更快被接受的可能性！
摘要应包含以下内容：
- 您的 PR 与哪个问题相关。
- 您的 PR 会带来哪些更改。
- 您如何测试更改。
- 您希望审核员仔细审核的任何内容。
- 您认为审核员需要的任何其他信息。
如果您在创建请求时遵循 PR 模板，应该就没有问题了。只需记得尽可能简洁且完整即可。
祝编码愉快！