拉取请求审查指南
对 Beats 所做的每一项更改都必须保持高标准。虽然拉取请求的质量责任最终在于作者，但 Beats 团队成员作为审查者，有责任在审查过程中进行验证。如果本文档不够清晰或不合适，请以常识和共识为准。
每个人对代码风格都有自己的看法。为了避免在这件事上浪费时间，我们几乎完全依赖 go fmt 和 hound 来检查风格。如果这两个工具都没有报错，那么代码基本可以确定没问题。这可能会有例外，但应该极其罕见。只有在最特殊的情况下，才去覆盖这些工具的判断。
随着软件项目的增长，其测试用例的复杂性也在增加，因此某些测试变得不稳定 (flaky) 的可能性也随之增加。处理不稳定的测试是每个人的责任。如果您发现拉取请求的构建失败，且原因与所推送的代码无关，请遵循以下步骤：
- 使用 GitHub 的 "Flaky Test" issue 模板创建一个 issue，并附上 "Flaky Test" 标签。
- 创建一个 PR 来屏蔽或修复该不稳定测试。
- 合并该 PR，并在继续您原始 PR 的正常流程之前，基于合并后的分支进行变基 (rebase)。