CI/CD 的分支策略
像制表符与空格一样，分支策略是引发在线和离线激烈辩论的情绪话题之一。
就像软件开发中的许多事情一样，关于最佳方法有许多坚定的观点，但正确的答案取决于上下文。 考虑到这一点，我们来看看什么是分支策略以及它们如何与 CI/CD 关联。
简而言之，分支策略是您的团队就如何以及何时在版本控制中创建和合并分支的协议。 您如何设置版本控制系统和使用分支将影响您如何设置 CI/CD 管道，因此选择满足您需求的模型至关重要。
DVCS 中的分支
随着使分支变得更加容易的分布式版本控制系统（尤其是 Git）的流行，分支策略成为开发团队的一个考量因素。
对于分布式系统，仓库有多个副本，因此有多个真实来源（尽管团队通常会指定一个中央副本或主副本）。 您和您的团队成员在仓库副本上并行处理您的更改，通过将更改推送到同一仓库的其他副本来共享您的工作。
Git 使创建分支和合并来自不同分支的提交成为一种非常轻量级的工作。 在 Git 中，分支只是一个标有特定名称的提交（或一组提交）。 分支非常适合包含一组更改，例如处理新功能或黑客实验。
随后，您可以通过将分支推送到另一个仓库并且/或者将其与另一个分支（例如 master 分支）合并以将其与代码库的其余部分合并来共享您的更改。 如果您决定不采用更改，也可以舍弃这些更改。 当您将两个分支合并时，Git 会负责对齐每个分支上的提交，并避免与在其他版本控制系统中合并相关的大部分复杂性。
为 CI/CD 使用分支
通过持续集成，重点是让开发团队中的每个人都经常提交他们的更改。 这意味着您可以定期测试一切是否按预期运行，而不是在代码编写完成后花费数周或数月的时间去尝试集成不同的工作流。 反过来，这也可以更经常地发布软件更新，从而发挥持续交付和部署的优点。
决定应当在哪里提交更改，应当何时运行自动化构建和测试，以及应当从哪里发布更新是分支的使用与 CI/CD 交互的地方。 最简单的方法（至少在概念上）是完全避免分支。 在基于主干的开发中，每个人都定期将更改提交到中央仓库的 master 分支，中央仓库保持可发布状态并且经常部署到生产中。
尽管基于主干的开发可以非常有效地运行，尤其是当您拥有成熟的 CI/CD 设置并且正在运行到托管系统的持续部署时，它也提出了一些挑战。 分支策略提供了管理代码更改的替代方法，这些方法拥有不同的优点和缺点。 下面是运行 CI/CD 的开发团队最常用的一些方法。
功能分支
顾名思义，创建功能分支是为了将各个功能与代码库的其余部分分开。 将正在进行的工作保持在 master 分支以外可以更容易地将 master 分支保持在可部署状态，并且如果您直接从 master 分支而不是发布分支（见下文）部署，则可避免将未完成的功能部署到生产。 您仍然可以通过将您的分支推送到中央仓库（如果您已指定一个）或任何其他仓库来与团队的其他成员共享您的工作。
功能分支的主要缺点以及基于主干的开发的拥趸经常对它们提出的批评是，如果将更改的集成延迟到功能“完成”，用户将失去持续集成带来的好处。 这可能会导致合并冲突并引入更复杂的错误，与迭代提交更改相比，这些错误需要更长的时间才能修正。
您可以通过设置 CI 服务器来缓解这些问题，以便在功能分支和 master 分支（或您用来准备发布的任何分支）上运行自动构建和测试。 这既可确保您从正在构建的内容的即时反馈中受益，同时还能降低合并更改时出现问题的风险。
最大限度减少合并冲突的一种方法是使功能分支保持短暂的生命周期，最多一两天。 另一种选项是定期基于 master 分支变基分支或合并来自 master 分支的更改。 这将使您的功能分支与提交给 master 分支的所有其他更改保持同步。 但是，如果您有大量并发功能分支都延迟提交到 master 分支，则仍然存在冲突的风险。
发布分支
功能分支提供了一种管理正在进行的工作的方法，而发布分支则用于在发布之前“强化”更改。 发布分支非常适合持续交付模型，其中更新是以一定间隔交付，而不是在准备就绪时立即交付，这样便可在生产中更轻松地支持多个版本。
使用发布分支工作流，一旦为特定发布计划的更改准备就绪，就会立即创建包含相关更改的发布分支（从 master 分支或另一个开发分支），之后不再合并其他功能。 同时，为其他发布计划的功能开发可以继续合并到 master 分支或其他地方。
发布分支构建随后进行一系列自动化测试，并在发布分支上进行任何错误修正，之后进行进一步的测试，直到您准备好发布。 这些错误修正也应当应用回 master 分支，以确保它们包含在未来的产品版本中。
只要您需要支持软件的每个版本，就可以保持您的发布分支，这样便可更轻松地将修正部署到旧版本。
需要更新时，可以在修补程序分支中或 master 分支上开发并正常测试，随后应用到发布分支（例如，通过优选）。
然后，它将经过该分支上的 CI/CD 管道，以确保在部署更改之前该版本没有任何问题。 或者，您可以直接在发布分支上完成工作，并在适用时将其应用回 master 分支。
修补程序分支
修补程序分支的操作类似于功能分支，但为了完整起见，值得一提。 修补程序分支的目标是将错误修正尽快应用到生产中。
您可以从 master 分支或发布分支创建修补程序分支，具体取决于您的部署位置。 与功能分支一样，您可以选择在修补程序分支上运行某些 CI/CD 元素，然后再将其合并到发布分支或 master 分支，以便在发布前进行进一步的自动化测试。
收尾工作
我们已经了解了在 CI/CD 工作流中使用分支的一些最常见方法，但还有更多不同的方法。
最重要的是找到适合您的特定上下文的策略。 采用持续改进的 DevOps 心态并对不同的选项保持开放态度，这样您便能够随着 CI/CD 做法的成熟不断调整方法来满足您的需求。