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

CI/CD 流程的不同之处有多大

CI/CD 管道使用基于主干的现代工作流程，在这种工作流程中，开发人员将频繁的小更新合并到主分支（或主干）中，该分支或主干是通过 CI/CD 管道的 CD 部分构建和测试的。该工作流程取代了 Gitflow 工作流程，在该工作流程中，开发和发布分支由发布时间表隔开。在许多组织中，Gitflow仍然是一种流行的版本控制和部署方法。但是，它现在被认为是遗留的，要集成到 CI/CD 管道中可能具有挑战性。

对于许多组织来说，从 Gitflow 工作流程到基于主干的工作流程的过渡尚未完成，结果是他们在此过程中陷入了困境，从未完全迁移到 CI/CD。不知何故，他们的管道最终会紧紧抓住传统工作流程的某些残余部分，陷入了过去和现在之间的过渡状态。查看 Git 工作流程的差异，然后了解使用传统工作流程会如何影响以下方面：

为了更轻松地识别现代配置中传统 Git 工作流程的残余部分，让我们将 Gitflow 与基于主干的现代方法进行比较。

Gitflow 方法

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

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

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

基于主干的方法

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

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