Master
技术

预检构建

NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions it is likely that it is still relevant. If the blip is older it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the RadarUnderstand more
Published: May 19, 2020
May 2020
评估?

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