预检构建

尽管相比 Gitflow 来说，我们强烈推荐 CI，但我们知道直接向主干提交然后在 master 分支上跑 CI，在团队过大的时候是低效的。构建会变慢或不稳定，也可能团队会缺乏在本地运行完整测试集的纪律。在这种情况下，一次红色的构建可以阻塞多名或多对开发者的工作。许多团队通常依赖功能分支来绕过这些问题，而不是解决潜在的根本原因——构建缓慢、不能本地运行测试或迫使许多人在同一位置工作的单体架构。我们不鼓励功能分支，因为它可能需要巨大的努力来解决合并冲突，并且还可能在解决冲突的过程中拉长了反馈周期和引入缺陷。取而代之的是，我们提议使用 预检构建 作为替代方案：它是基于 Pull Request 的构建，针对只在流水线运行期间存在的为每个commit建立的微型分支。为了自动化这一工作流，我们已经见到了类似 Bors 这样的机器人程序，它将合并 master 分支和删除迷你分支（当构建成功时）的工作自动化。我们正在评估这个流程，你也应该试试看，但请不要用它去解决错误的问题，因为这样的话可能会带来分支滥用，导致弊大于利。