git作为版本管理系统提供了强大的跟踪，管理和组织代码 的能力，为开发者减少版本管理的时间。但协作开发时需要遵循某种规则来保证提交的代码不会影响其他人的开发。 建立一组规则特别有必要， 可以减少提交冲突，降低合并错误，提高开发者之间合作的愉快度。我们认为branch是一条独立的代码提交线路，以branch为单元，组织 一系列规则，branch 策略的好处如下：

1. 提供开发者平行的开发能力
2. 组织一系列有计划组织的发布
3. 提供一条清晰提交修改路径
4. 提供独立主线版本的问题修复的能力

下面我们介绍几种已知的branch管理策略：

gitflow branch管理策略

gitlfow策略将管理分为如下多个branches:

1. master branch
2. develop branch
3. feature branch, 开发新feature时候从develop branch分出，开发完毕回到develop分支
4. release branch, 发布时从develop branch 分出，修复验证完毕后同时回到develop branch 和 master branch
5. hotfix branch, 紧急修复从master branch分出，修复验证完毕同时回到master branch 和 develop branch

详细过程可以看图：

优势:

1. 多个分支，可以提高更高的灵活性
2. 更加有效的测试支持
3. release branch让开发者非常简单持续支持多版本

劣势：

1. 此策略可能过于复杂，减缓开发进度，延长发布周期
2. 由于很长的开发周期，导致对CICD支持不友好

githubflow branch管理策略

github flow 比 git flow简单适合小的team，或者不需要多版本支持的场景。

1. master branch 代表最稳定的代码
2. feature branch 代表新的feature，bug fixed， 修复验证将会被merge回master branch

详细过程如下图：

优势：

1. github flow branch管理策略十分简单
2. 支持CICD
3. 适合小团队和web开发

劣势：

1. 不支持多版本管理
2. 由于没有develop branch，github flow的master分支代码更容易产生bug

gitlab flow branch管理策略

gitlab flow 吸取了git flow 和 github flow的优点，有不同的开发环境和单一主分支的简单和便利。gitlub flow的原则是"upstream first", 只存在一个master主分支，他是其他分支的上游，只有上游分支代码被采纳，才会运用到其他下游分支。gitlab flow 有2种方式：

1. version release, release 版本从master branch分出，只有bug fixed才允许将代码(cherry-pick)到这些分支，并且更新版本号, 如下图：

2. continuos release，从master分支分出新的环境分支， 比如新的开发分支master， 预发布分支pre-production, 生产分支production。代码变化必须从上游到下游发展，如果遇到一个bug ，需要新建一个分支，先把修复后分支合并到master， 再cherry-pick到pre-production, 确认没问题，在cherry-pick到production, 如图：

优势：

1. gitlab flow相对git flow 要简单
2. gitlab flow 比github flow更有组织
3. 对于小修复，gitlab flow 可持续CD和版本发布

劣势:

1. gitlab flow 其实不简单
2. gitlab fow 不是最有结构性的策略，往往会导致协作混乱