一、背景：

Git是目前最为主流的代码管理工具，当在新迁出的分支进行代码修改，优化，增加功能时，提交的代码并不会影响到主干的代码，这样就会保证我们的主分支上的代码不会受到影响。

一个规范的git管理策略有助于项目的后期迭代和维护，也有助于多人协作开发。

项目开发的生命周期一般是这样的，需求评审 =》技术方案调研 =》技术方案评审 =》工程开发 =》工程联调 =》测试环境测试 =》预发布环境测试 =》发布生产环境 =》生产环境回归

二、常见的四种git管理策略

目前常见的git管理策略有四种：Git Flow、GitHub Flow、GitLab Flow、TrunkBased。

1、Git Flow

Git Flow是最早出现一种分支管理策略，它由两个长期分支和三种临时分支组成。

master 主分支, master 分支上的代码是最稳定的代码，随时可以发布到生产环境。
develop 最新开发版本分支，当该分支代码稳定，可发布版本时，合并到master分支上。
feature 功能模块分支，开发新功能时以feature/xxx命名，开发完成后，合并到develop上，并删除该分支。
release 版本预发布分支，当v1.0.1版本发布时，从develop分支迁到release/xxx，进行测试，测试出现问题，在release/xxx 分支上进行修改，测试完毕后代码没有问题，将代码合并至master和develop分支上，给master打上v1.xx版本名称的标签，合并后删除该分支。
Hotfix 线上紧急bug修复的分支，以hotfix/xxx命名，修改完成后，合并到master和develop分支，合并到master后打上修复版本的tag，合并后删除该分支。

2、GitHub Flow

GitHub Flow是由GitHub 制定的分支策略，是开源社区惯用的一种分支策略，

只有一个长期分支 master，其他分支都在其基础上创建。

不用区分什么功能分支或者bug修复等分支，按照相应要求切换相应分支名，但是取的分支名还是需要有相应描述，这样看到分支名也大概知道此分支是关于什么的。

当相应分支功能开发完毕之后，需要向master分支提起pull request，请求合并到master分支。

通常在pull request这个阶段，会对代码进行code review，代码没有问题时便进行合并

3、GitLab Flow

GitLab Flow出现的较晚，但是它吸收了其他分支管理策略的优势。

Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即、只存在一个主分支 master，是所有其他分支的"上游"。只有上游分支的代码变化，才能应用到其他分支。

它建议每个环境都去建立对应的分支。比如预发布环境分支pre-production、生产环境分支production，从上游到下游，当开发分支上的代码开发完成以后，会合并到最上游master，经过测试没有问题后，会合并到pre-production分支，再进行测试，没有问题后将合并到production分支，并发布到生产环境。

gitlab flow 对于版本发布的项目，建议的做法是每一个稳定版本，都要从 master 分支拉出一个分支，比如 2-3-stable、2-4-stable 等。

在出现 bug 后，根据对应的版本分支创建一个修复分支，修复工作完成后，一样要按照上游优选的原则，先合并到 master 分支，经过测试才能够合并到 release 分支，并且此时要更新小版本号。

4、TrunkBased

Trunk Based Development，又叫主干开发。

代码仓库就只有一个master分支了。开发团队成员可以一天内多次将代码提交到主干分支，使团队的工作在24小时内就可以被整合，保证了代码版本随时处于可发布的状态。避免长期存在多个分支，有利于持续集成和持续交付。

发布时直接从主干分支上创建release分支，并打上tag，发布完成后删除release分支。换句话说，发布分支是主干分支某个时点的快照。

主干开发要求每次提交都是一个可上线的版本，因此会出现如下问题：

1、如何避免发布的时候引入未完成的 feature:

在代码中增加特定的开关控制新特性的展示

2、如何进行线上 bug fix

在发布时打上 release tag，一旦发现这个版本有问题，如果这个时候 master 分支上没有其他提交，可以直接在 master 分支上进行修改，如果 master 分支已经有了提交就要做以下四件事：

    从tag处创建release分支
    在master上修复bug
    将修复bug的提交cherry pick到release分支
    在release分支上打tag并发布

三、这里简单介绍一下git tag的用法

创建对应的tag，并关联对应的commitId

git tag -a <标签名> <commitId> -m '标签内容文字描述'

将代码切换到某个标签

git checkout -b <tagName>

四、总结

目前大部分团队用的应该是git flow 加 github flow 这两种方式的组合，通过分支的划分，以及代码的pull request , code review之后再进行，确保主干分支代码的稳定。

Git分支管理策略