2021 使用最多的代码分支策略

Blog
Author:
Guy GolanGuy Golan
Published On:
4月 10, 2021
Estimated reading time:
1 minute

随着远程开发兴起,分支策略的关注也自然而然增多,所以我们接下来将看看 2021 年使用最多的分支策略。为了确保项目的代码库得到保护,一次性实现多个更改,分支策略必不可少。如果开发团队较小,事情很简单。然而,人多手杂,开发人员一多,混乱也就产生了。

为什么团队需要分支策略?

如果你的开发团队人数较多,且两人同时在同一组件开发时,我们可能会需要分支策略。如果两人操作的组件不同,则可以借助适当的互操作性。 团队成员之间需要一种方法来协调代码更改,以确保工作能够顺利进行。

CI/CD 进程,为实施分支策略提升稳定性创造了机会。正确的代码分支策略不但帮助安全的功能创建、修复错误,还能促进团队创新。

有时,开发人员需要机会在代码中创新。例如使用新版本的库帮助程序顺利运行,或者启用新功能。通过分支,开发人员可以在本地测试更改,将其推送到团队的代码库,并让 CI/CD 进程运行以查看这些更改如何影响产品。

在整个过程中,更改进入生产, 主干分支也得到安全维护。版本中使用的任何功能分支、错误修复或依赖关系都会合并回主干分支,并且不断循环!

功能代码分支策略

团队的任务分配与其选择的分支策略有关。许多项目管理包具有与代码库集成的功能,借助这些功能,开发人员可以启动一个新的功能分支,并直接切换进行更改。

这也称为任务分支,让团队中的不同成员可以独立地完成多个任务。开发人员各自的任务提交互不干扰,所做的更改也不会损害项目或组件。任务提交、合并,最终形成了一个可交付的候选版本。其中,稳定的主干分支是合并其他分支的基础。

这种分支策略或其他分支策略,有利于直接跟踪对初始请求的更改。在当今世界,许多行业都有责任链,这一点至关重要。为了保持一定的认证,一些公司必须严格审查任何对影响数据安全或标准遵从的更改。

发布代码分支策略

Release-Branching-Strategy

这是功能分支的扩展。选择发布分支的团队通常创建分支进行代码修改。这些更改然后可以在其管道的 CI 系统中循环,以检查编译甚至遵从性问题。 发布分支和功能分支的关键区别在于如何处理发布。

发布分支允许功能分支向前合并到版本化的“发布”中,而不是向后或水平地合并,让其他开发人员的更改。这种向前修复方法是 web 应用程序敏捷开发的一个关键方面,帮助工程师构思,实现更大的目标。

主干开发

相反,主干开发需要完成大量的合并。CI/CD 进程的各个方面,例如自动化测试、代码覆盖和持续交付,都需要完成,这并不容易。

由于需要大量的合并,开发人员倾向于将代码更改最小化。在这些小的代码片段上对每个更改进行更密集的测试和实验,保持代码库准确无误。

团队只需“Git”一下

市场上有很多开源的代码控制系统支持分支策略,但没有一个像Git那样风靡软件开发行业。选择 Git 的开发者数量逐年增加,这不足为奇。

作为一个存储库,Git 提供了大量复杂的功能,尤其是与其他开源代码控制系统(如 Mercurial)相比。Git 的方法善用敏捷软件开发,帮助团队高效完成工作。

Git 受欢迎的另一个原因是提供了 GitHubGitLab 等云产品。这些云产品不仅符合 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,并与任务处理集成的公司,可能会放弃这种方法,转而采用分支模型。

banner-CI_CD