拉取请求审查指南
编辑拉取请求审查指南编辑
对 Beats 的所有更改都必须符合高标准，虽然拉取请求的质量最终责任在于作者，但 Beats 团队成员有责任在他们的审查过程中进行验证。如果本文档不清楚或不适用，请以常识和共识为准。
代码风格编辑
每个人都对风格有自己的看法。为了避免在这方面浪费时间，我们几乎完全依赖 go fmt 和 hound 来监管风格。如果这两个工具都没有报错，代码几乎可以肯定没问题。可能会有例外情况，但应该非常罕见。只有在最不寻常的情况下才覆盖这些工具的判断。
不稳定的测试编辑
随着软件项目的发展，测试用例的复杂性也会增加，随之而来的是一些测试变得不稳定的可能性。每个人都有责任处理不稳定的测试。如果您发现拉取请求构建失败，原因与推送的代码无关，请按照以下步骤操作
- 使用 "Flaky Test" github 问题模板创建问题，并附上 "Flaky Test" 标签。
- 创建 PR 来静默或修复不稳定的测试。
- 合并该 PR 并重新基线到它，然后再继续您原始 PR 的正常 PR 流程。