随着远程开发兴起，分支策略的关注也自然而然增多，所以我们接下来将看看 2021 年使用最多的分支策略。为了确保项目的代码库得到保护，一次性实现多个更改，分支策略必不可少。如果开发团队较小，事情很简单。然而，人多手杂，开发人员一多，混乱也就产生了。
为什么团队需要分支策略？
如果你的开发团队人数较多，且两人同时在同一组件开发时，我们可能会需要分支策略。如果两人操作的组件不同，则可以借助适当的互操作性。 团队成员之间需要一种方法来协调代码更改，以确保工作能够顺利进行。
CI/CD 进程，为实施分支策略提升稳定性创造了机会。正确的代码分支策略不但帮助安全的功能创建、修复错误，还能促进团队创新。
有时，开发人员需要机会在代码中创新。例如使用新版本的库帮助程序顺利运行，或者启用新功能。通过分支，开发人员可以在本地测试更改，将其推送到团队的代码库，并让 CI/CD 进程运行以查看这些更改如何影响产品。
在整个过程中，更改进入生产， 主干分支也得到安全维护。版本中使用的任何功能分支、错误修复或依赖关系都会合并回主干分支，并且不断循环！
功能代码分支策略
团队的任务分配与其选择的分支策略有关。许多项目管理包具有与代码库集成的功能，借助这些功能，开发人员可以启动一个新的功能分支，并直接切换进行更改。
这也称为任务分支，让团队中的不同成员可以独立地完成多个任务。开发人员各自的任务提交互不干扰，所做的更改也不会损害项目或组件。任务提交、合并，最终形成了一个可交付的候选版本。其中，稳定的主干分支是合并其他分支的基础。
这种分支策略或其他分支策略，有利于直接跟踪对初始请求的更改。在当今世界，许多行业都有责任链，这一点至关重要。为了保持一定的认证，一些公司必须严格审查任何对影响数据安全或标准遵从的更改。
发布代码分支策略
这是功能分支的扩展。选择发布分支的团队通常创建分支进行代码修改。这些更改然后可以在其管道的 CI 系统中循环，以检查编译甚至遵从性问题。 发布分支和功能分支的关键区别在于如何处理发布。
发布分支允许功能分支向前合并到版本化的“发布”中，而不是向后或水平地合并，让其他开发人员的更改。这种向前修复方法是 web 应用程序敏捷开发的一个关键方面，帮助工程师构思，实现更大的目标。
主干开发
相反，主干开发需要完成大量的合并。CI/CD 进程的各个方面，例如自动化测试、代码覆盖和持续交付，都需要完成，这并不容易。
由于需要大量的合并，开发人员倾向于将代码更改最小化。在这些小的代码片段上对每个更改进行更密集的测试和实验，保持代码库准确无误。
团队只需“Git”一下
市场上有很多开源的代码控制系统支持分支策略，但没有一个像Git那样风靡软件开发行业。选择 Git 的开发者数量逐年增加，这不足为奇。
作为一个存储库，Git 提供了大量复杂的功能，尤其是与其他开源代码控制系统（如 Mercurial）相比。Git 的方法善用敏捷软件开发，帮助团队高效完成工作。
Git 受欢迎的另一个原因是提供了 GitHub 和 GitLab 等云产品。这些云产品不仅符合 Git 存储库标准，而且还具有一系列功能，增强 DevOps 自动化。
顺“flow”而为
有两种方法可以很好地处理这些分支策略，比当今的软件开发世界中的大多数方法都更为合拍。Gitflow Workflow 和 GiHub Flow 的基本理念，都是使用 Git 功能分支来修改和部署代码，避免实际接触“主干”分支，帮助相关工作团队提升开发速度。
Gitflow Workflow
对于今天的许多项目来说，Gitflow Workflow 有点复杂。但自从 2010 年以来，其使用率一直居高不下。开发团队可以在主干上创建的分支，进行更改和缺陷修复，这也让开发变得更为灵活自由。发布分支得到识别，并通过独立的进程来编译、测试和部署更改。
在部署之前不向主干分支提交更改，因此其他敏捷开发开始时，避免了引入错误和逻辑问题。这种对代码库的保护是团队选择分支策略的一个重要原因。
另一方面，Gitflow 便于组织更改。开发人员创建的功能分支与协调其他发布命名分支一起工作，这有助于合理进行合并，及其他分支管理。
- 主干分支（master） —包含了所有正在生产的代码库，这些代码已完成提交，经历了整个流程，并在发布验证后合并。
- 开发分支（develop）—这是保存当前最新开发成果的分支，包含所有合并的功能分支。通常用于运行自动化测试，并通过 CI/CD 管道发布到开发资源。
- 功能分支（feature）—新版本中的每个更改都在与项目任务相关的功能分支中完成。
- 热修复分支（hotfix）—类似于功能分支，可以从主干分支派生。在不影响当前开发的情况下，修复程序以继续支持生产。任何更改都可以并入活跃的功能分支/或并回主干分支，以确保不会重新引入问题。
- 发布分支（release） —这个分支是计划发布的所有功能分支的终点，为发布新的产品版本而设计。这个分支将等待最终生成，所有的更改在验证及发布成功后，合并回主干分支。
GitHub Workflow
在大方面，GitHub Workflow 可与 Gitflow Workflow 相提并论。发布持续进行，这有利于团队不断进行修改，并且在生产之前经常检查这些更改。
GitHub Workflow 假定主干分支中的内容是应该部署的内容，而不是发布命名分支的内容。开发人员仍然使用功能分支来将其更改建立在主干分支的基础上，但是依赖于拉取请求和代码检查来控制进入生产的内容。
这个工作流程有利于连续部署和向前修复。不用等到 sprint 周期的结束，开发人员就可以开展其他工作。同时，团队成员间还可以互相检查代码，增强了团队互动。
总结
这些分支策略在软件开发中的地位不断得到巩固。你的团队使用哪种代码分支策略，取决于你们产品和发布过程。在大多数情况下，开发团队使用发布分支来进行与任务系统一致的更改，并能支持发布周期的不同阶段。
其他人则喜欢用简单的功能分支来提高速度。在两种情况下，主代码库都能得到保护，且开发人员可以在代码的各部分努力工作。鉴于 CI/CD 在这些 功能分支上的能力，几个开发人员可以同时检测新功能和这些现成的 bug 修复方法，而不会耽误开发过程。
使用主干开发或主干分支进行开发的工作流程越来越少。与其他备受推崇的方法相比，主干开发在管理上尤其麻烦。随着技术的进步，那些在SaaS 平台上使用 Git，并与任务处理集成的公司，可能会放弃这种方法，转而采用分支模型。
