本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# CI/CD 流程的不同之处有多大
CI/CD 管道使用*基于主干的现代工作流程，在这种工作流程*中，开发人员将频繁的小更新合并到主分支（或主*干*）中，该分支或主干是通过管道的 CD 部分构建和测试的。 CI/CD 该工作流程取代了 *Gitflow 工作流程*，其中的开发和发布分支通过发布计划分开。在许多组织中，Gitflow 仍然是一种流行的版本控制和部署方法。但是，它现在被认为是遗留的，要集成到 CI/CD 管道中可能具有挑战性。
对于许多组织而言，从 Gitflow 工作流程到基于主干的工作流程的转换尚未完成，导致它们在迁移过程中停滞不前，从未完全迁移到 CI/CD。不知何故，它们的管线仍然保留旧版工作流程的某些残余，卡在过去与现在之间的过渡状态。查看 Git 工作流程中的差异，然后了解使用旧版工作流程对以下方面有何影响：
+ [环境完整性](environment-integrity.md)
+ [发行版](releases.md)
+ [安全性](security.md)
为了更轻松地识别现代配置中的旧版 Git 工作流程残余，让我们比较一下 [Gitflow](#gitflow-approach) 与[基于主干](#trunk-based-approach)的现代方法。
## Gitflow 方法
下图显示 Gitflow 工作流程。Gitflow 方法使用多个分支同时跟踪多个不同版本的代码。您可以计划在未来某个时间点发布应用程序更新，而开发人员仍对当前版本的代码继续开发。基于主干的存储库可以使用功能标志来实现此目的，但 Gitflow 默认内置此功能。
Gitflow 方法的结果之一是应用程序环境通常不同步。在标准 Gitflow 实施中，开发环境反映了代码的当前状态，而预生产和生产环境则冻结在最新版本的代码库状态。
当生产环境中出现缺陷时，情况会变得复杂，因为如果不暴露未发布的功能，开发人员使用的代码库就无法合并到生产环境中。Gitflow 处理这种情况的方式是使用修补程序。从发布分支创建修补程序分支，然后直接部署到上层环境。修补程序分支随后合并到开发分支，以使代码保持最新。
## 基于主干的方法
下图显示基于主干的工作流程。在基于主干的工作流程中，开发人员在功能分支中本地构建和测试功能，然后将这些更改合并到主分支中。然后，按顺序将主分支构建到开发、预生产和生产环境。每个环境之间都会进行单元测试和集成测试。
使用此工作流程，所有环境都运行相同的代码库。上层环境不需要修补程序分支，因为您可以在主分支中实施更改，而无需暴露未发布的功能。始终假定主分支是稳定、没有缺陷且随时可以发布。这可以帮助您将其集成为 CI/CD 管道的来源，该管道可以在管道中的所有环境中自动测试和部署您的代码库。