书接上文
在前一篇文章 GIT 代码分支管理模型之一中，我们一起了解了一种叫做“成功的代码分支管理模型”。在这种模型中，我们确实可以很灵活地应对各种场景下的代码分支管理。
理想总是那么美好，而现实偏偏那么蛋疼！
要用好这种代码分支管理模型，需要全体开发人员对于 GIT 有比较深入的了解，比如 merge, rebase, 而且在每一次 GIT 的操作的时候要很清楚地知道自己正在开发的功能属于哪个分支的。对于同时开发多个功能点的同事来说，比如同时在开发一个下一版本的功能，以及进行产品线上细微改动的同事来说，确实要非常小心，稍不留神就容易怼错分支。
历史背景
在我们公司刚开始推行 GIT 的时候，领导下的指令是要让大家把精力全放在功能开发上，对于 GIT 只需要知道 pull 跟 push 就可以了，经过一段历史时期的挣扎磨合，无形中我们形成了下面这种分支管理模型，称之为 “ 简单但啰嗦的分支管理模型 ”
简单但啰嗦的分支管理模型
主心骨
这个模型主要有两种分支，一种叫 DEV，一种叫 REL。每一种后面都附加有对应版本号，比如 DEV1.0, REL1.0
RELx.0
每个版本开始开发之前，都会从上一个版本的 REL 分支创建出一个新的 REL 分支，比如 REL2.0 是从 REL1.0 创建出来。当然第一个版本 REL1.0 就是从 master 分支创建出来的。这样就确保了每一个版本都是从上一个版本最新代码创建出来的。
RELx.0 神圣职责是作为每一个大版本发布的分支，并且是用来部署测试环境，准产品线以及产品线的分支。一般开发人员没有权限直接往 RELx.0 上面提交代码，只能从对应的 DEV 分支提交代码，再由集成人员合并到上面去。
DEVx.0
DEVx.0 是与 RELx.0 对应的开发分支，所有开发人员默认都有权限往这个分支上提交代码。这也是开发人员所需要知道的分支，只需要从这上面 pull 最新的代码，然后把本地 commit 的代码 push 到上面去就可以了。
小版本怎么办？
在相当长的一段历史时期中，基本稳定在一个版本一个月左右。但有时会遇到有些小功能着急着上，等不及一个月上一次，所以就有了对应 RELx.x 以及 DEVx.x (x > 0). 比如刚发布了 REL3.0，这时有 VIP 客户需要上一个功能，改动不至于很大，但是也等不及下个月再上，于是我们就从 REL3.0 上面衍生出一条 REL3.1 的分支。按照之前的规则，REL 分支是不允许直接修改代码的，所有对应的我们会创建 DEV3.1 的分支，给开发人员在上面进行开发。
在这个过程中，下一版本 4.0 其实一直在同步进行开发的，但是这时 REL4.0 以及 DEV4.0 的分支上是没有 DEV3.1 的新功能的，所有在 3.1 的新功能上线之后，需要由持续集成人员 DEV3.1 的代码合并到 DEV4.0 上面去（为什么不是直接 REL3.1 到 REL4.0 呢? 技术上是可行的，但是这样的话，REL4.0 需要反向将代码合并会 DEV4.0 去，比较别扭），持续集成环境会自动将 DEV4.0 的新代码合并到 REL4.0 上面去，这样到时发布 4.0 的时候，才不会丢失了 3.1 新增的功能
没 bug 的系统是不完整的
有 bug 怎么办？
不管是大版本还是小版本，总有可能产品线上有 bug 需要 hotfix。在上次介绍的成功代码分支模型中，可以通过 hotfix 的分支进行代码修复。但在这个简单模型中，就不会新建 hotfix 的分支，而是在最新以上线的分支上进行修改。比如当前产品线上是 REL3.0 的代码，REL4.0 是下一个大版本，REL3.1 是准备上线的小版本，而这时产品上客户报了 Level 1 的 case，按照 SLA 需要在三天内修复，我们是等不及 REL3.1 下周末上的，更不可能等 REL4.0 到下个月，所有我们要上到 3.0 的分支上：
已上线的 REL3.0 以及对应的 DEV3.0 在上线之后就全被锁掉了，所以这时我们要找代码集成人员进行解锁
然后在 DEV3.0 的分支上进行代码修复，直到测试通过后，合并代码分支到 REL3.0 进行紧急上线
简单但啰嗦
简单
这种模型中，大部分开发人眼只需要记住版本的 DEVx.x 就可以了，其它 REL 什么的都可以不用管，不懂也没关系的。
啰嗦
每一个新版本开发前，管理人员都要新建对应的 DEV 分支，然后开发人员 checkout 对应分支进行开发。这样一来，一个版本，无论大小，都需要对应有两条分支，整个代码库看起来就有很多很多的分支，略显啰嗦。
there is no free lunch!
利弊关系上面已经做了一些简单的介绍，这种模型适合在项目比较大，团队人数较多的情况下使用，好处是开发人员不需要对 GIT 有过深的理解，只需会简单的 pull / push，其它都由分支管理以及对应的权限管理搞定；其缺点也明显，就是整个代码库会有好多好多的分支，看起来比较啰嗦。