本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

完全 CI/CD 流程有何不同

CI/CD 管线使用基于主干的现代工作流程，开发人员在此将频繁的少量更新合并到主分支（或主干）中，后者通过 CI/CD 管线的 CD 部分进行构建和测试。该工作流程取代了 Gitflow 工作流程，其中的开发和发布分支通过发布计划分开。在许多组织中，Gitflow 仍然是一种流行的版本控制和部署方法。但是，它现在已被视为旧版方式，可能难以集成到 CI/CD 管线中。

对于许多组织而言，从 Gitflow 工作流程到基于主干的工作流程的转换尚未完成，导致它们在迁移过程中停滞不前，从未完全迁移到 CI/CD。不知何故，它们的管线仍然保留旧版工作流程的某些残余，卡在过去与现在之间的过渡状态。查看 Git 工作流程中的差异，然后了解使用旧版工作流程对以下方面有何影响：

为了更轻松地识别现代配置中的旧版 Git 工作流程残余，让我们比较一下 Gitflow 与基于主干的现代方法。

Gitflow 方法

下图显示 Gitflow 工作流程。Gitflow 方法使用多个分支同时跟踪多个不同版本的代码。您可以计划在未来某个时间点发布应用程序更新，而开发人员仍对当前版本的代码继续开发。基于主干的存储库可以使用功能标志来实现此目的，但 Gitflow 默认内置此功能。

Gitflow 方法的结果之一是应用程序环境通常不同步。在标准 Gitflow 实施中，开发环境反映了代码的当前状态，而预生产和生产环境则冻结在最新版本的代码库状态。

当生产环境中出现缺陷时，情况会变得复杂，因为如果不暴露未发布的功能，开发人员使用的代码库就无法合并到生产环境中。Gitflow 处理这种情况的方式是使用修补程序。从发布分支创建修补程序分支，然后直接部署到上层环境。修补程序分支随后合并到开发分支，以使代码保持最新。

基于主干的方法

下图显示基于主干的工作流程。在基于主干的工作流程中，开发人员在功能分支中本地构建和测试功能，然后将这些更改合并到主分支中。然后，按顺序将主分支构建到开发、预生产和生产环境。每个环境之间都会进行单元测试和集成测试。

使用此工作流程，所有环境都运行相同的代码库。上层环境不需要修补程序分支，因为您可以在主分支中实施更改，而无需暴露未发布的功能。始终假定主分支是稳定、没有缺陷且随时可以发布。这可以帮助您将其作为 CI/CD 管线的源代码进行集成，从而可以通过管线中的所有环境自动测试和部署您的代码库。