团队Git分支管理策略
目前通用分支管理策略
Git flow、GitHub flow和GitLab flow。三种工作流都有一个共同电：都采用“功能驱动式开发”。需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
下面主要讨论一下Git flow，这个目前也是用的比较多的分支管理策略。
首先，项目存在两个长期分支。
主分支master
开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
开发团队遇到问题
团队中采用GitLab来进行代码托管，为了提高代码质量，需要增加Code Review逻辑，引入Merge Request模式，研发团队不可以直接push代码到develop、release和master等分支。
目前分支管理策略
master：归档分支。每个版本结束后把release_x.x.x分支代码merge过来。
hotfix_x.x.x_h：补丁分支。一个补丁版本对应一个分支，x.x.x_h为版本号。hotfix分支原则上基于release分支创建，例如：hotfix_9.3.1_h1需要基于release_9.3.1分支创建。
release_x.x.x：提测分支。一个常规版本对应一个分支，x.x.x为版本号。版本提测时基于develop分支创建。
develop：开发分支。所有功能均在该分支开发。
修复bug时，在develop分支上面修复，然后cherry-pick到对应release_x.x.x分支。
引发问题
因为需求需要快速迭代，然后原计划V1.0.0升级版本因为特殊原因不能发布，后面的V1.0.0_h1版本又要发布，导致需要在develop回退代码之后，在开发功能，然后基于develop拉齐对应release分支。等到对应版本(V1.0.0)功能要上线时，又需要在develop补齐代码。在代码回退不干净时，会引发1.0.0版本的代码，随着1.0.0_h1代码上线。本质上，版本发布不是按照上一个版本发布完成，才发布下一个版本。
实践中选择分支管理策略
经过团队内容多次实践并运行快2年，得出了团队实践中相对完善的分支管理策略
master：归档分支，只有1个。每个版本结束后把release_x.x.x分支代码merge过来。
release_x.x.x和hotfix_x.x.x_h*分支。不同版本拉取对应的分支，有多个，根据发布版本需求拉取分支。
feature_x.x.x，对应release或者hotfix的版本。比如有release_1.0.0分支，对应就有feature_1.0.0，有hotfix_1.0.0_h1分支，对用的就有feature_1.0.0_h1分支。所有研发团队在feature_x.x.x分支开发，然后Merge Request到对应release或者hotfix分支。
分支管理策略建议
在快速敏捷迭代开发中，Git分支管理策略至关重要。通过有效的分支管理，团队可以更轻松地协同工作，避免冲突并保持代码的整洁。以下是一些建议的策略：
- 主干开发策略
在主干开发策略中，主分支是主要的工作分支，应该保持最新和可运行的状态。所有开发人员都在主分支上进行开发，并在完成功能后进行合并。这种策略适用于较小的团队或较简单的项目。
- 功能分支策略
功能分支策略是每个开发人员拥有自己的分支，用于开发和测试特定功能。在完成功能后，开发人员将分支合并到主分支。这种策略适用于较大的团队或较复杂的项目。
3.发布分支策略
发布分支策略是在每个发布周期中创建一个新的分支，用于测试和发布。在测试阶段中，开发人员将新功能合并到发布分支中，并在需要时进行修复。在发布完成后，发布分支可以被删除并从主分支重新创建。