本文目标

技术经理实质是具备很多技能的，git版本管理则是其中之一。

此篇文章只谈git版本如何管理，别的不扯，干净利索！！！

《技术经理必备技能-git版本管理》

正文

git 版本管理 关注的事情

git 版本管理 要考虑如下几个事情：

1、版本如何管理

2、git分支如何管理

3、研发分支从哪个分支拉取

4、代码分支怎么合并

5、环境划分，git分支和环境的对应关系

6、并行需求时候，这么管理研发分支，以及怎么转测

7、紧急需求、线上问题如何快速处理

8、功能不会遗漏

git 版本管理的几种方式

1、简单式

2、B模式

3、C模式

简单式

适用的场景具备如下条件（并不绝对）：

1、团队人数<10人

2、标准的2个环境，研发环境、测试环境、[灰度环境、]生产环境

3、基本的3个git分支，develop、test、master，并且和3个环境一一对应

4、项目版本节奏很稳定、不会出现并行需求

5、没有特殊情况下，3个环境和3个git分支能对应上，灰度环境基本是临时的

 1） 研发环境  -> develop
 2)  测试环境  -> test 
 3)  生产环境  -> master

git分支管理方式：

基本情况是，有3个环境[灰度环境不计算在内]，研发环境、测试环境、生产环境。

同时有3个重要分支 develop 、 test 、 master ，分别对应3和环境 。

1、日常迭代模式

1） 研发分支在develop，或者从develop 上拉新分支（推荐做法是拉新分支）

2） 代码合并方向是从研发分支 -> develop -> test -> [pre] master -> release/VX.M.N[或者tag V.X.M.N] 。

3）不处理并行需求

日常迭代分支流向 参考下图 ：

[feature]

2、hotfix模式 1） 从生产分支拉研发分支，hotfix

2） hotfix 研发完成后，直接灰度环境（test可以代替灰度）
切记，在没有验收的情况下，不能发布生产环境（小心驶得万年船！！！）

3） 代码回合，正常的研发分支从哪里拉，则hotfix 发布生产后必须[必须、必须、必须]回合，然后再回合到具体的在途研发分支。

hotfix 模式，用使用于解决如下2种场景：

1、 线上问题紧急修复（被动的方式）

2、线上迭代紧急需求

3、线上漏洞（主动发现或者开源组件影响死一大片情况）

hotfix 分支 流向 参考下图 ：

[hotfix]

3、bugfix 模式 bugfix 模式，是在日常迭代模型下，测试人员在测试环境上提出的问题（或者产品、业务验收人员在灰度环境提出的问题）。

该问题对生产不会影响，只会影响本次版本的转测情况，按照研发bug方式进行修复。