本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 基于主干的方法对环境完整性的优势 正如许多开发人员所知道的那样，一次代码更改有时可能会产生[蝴蝶效应](https://www.americanscientist.org/article/understanding-the-butterfly-effect)（American Scientist 文章），即一个看似无关的微小偏差会引发连锁反应，导致意想不到的结果。开发人员随后必须进行全面调查以找出根本原因。 科学家进行实验时，会将受试者分为两组：实验组和对照组。目的是使实验组和对照组除了实验测试内容之外完全相同。如果实验组中出现了对照组中没有出现的情况，那么唯一的原因就是测试的内容。 将部署中的变更视为实验组，将每个环境视为独立的对照组。仅当下层环境的对照组与上层环境的对照组完全相同时，下层环境的测试结果才是可靠的。环境偏差越大，在上层环境中发现缺陷的可能性就越大。换句话说，如果代码变更将在生产环境中失败，我们宁愿其先在测试版中失败，这样它们就永远无法投入生产。这就是为什么应尽一切努力使每个环境（从最低测试环境到生产环境本身）保持同步的原因。这称为*环境完整性*。 任何完整 CI/CD 流程的目标都是尽早发现问题。使用基于主干的方法保留环境完整性，几乎可以消除对修补程序的需求。在基于主干的工作流程中，问题很少会首先出现在生产环境中。 在 Gitflow 方法中，将修补程序直接部署到上层环境后，再将其添加到开发分支中。这会保留该修复程序以备未来版本使用。但是，该修补程序是直接根据应用程序当前状态开发和测试的。即使该修补程序在生产环境中完美运行，当其与开发分支中的较新的功能交互时，也有可能出现问题。由于通常不希望为修补程序部署修补程序，因此这会导致开发人员花费额外的时间尝试使该修补程序重新适配开发环境。在许多情况下，这可能导致巨额技术债务，并降低开发环境的总体稳定性。 环境中发生故障时，所有更改都会回滚，以使环境恢复到其以前的状态。对代码库的任何更改都应从第一阶段重新启动管线。当生产环境中确实出现问题时，修复也应该通过整个管线进行。与使用此方法可避免的问题相比，经过下层环境所花的额外时间通常可以忽略不计。由于下层环境的全部目的是在错误进入生产环境之前将其捕获，因此通过 Gitflow 方法绕过这些环境是一种效率低下且不必要的风险。