就像人心散，队伍不好带一样，代码版本多，分支也不好管
当产品开发到一定程度后，多版本同时开发，各种热修复等等问题，势必会带来版本分支管理的问题。今天我们准备一起来看看第一种代码分支管理方案。
这里要先强调一下，分支管理的方式各有千秋，不存在谁一定比谁好，只有谁比谁更适合你而已
热门的成功代码分支管理
这款人们的分支管理方案只要是从这篇叫 A Successful Git Branching Model 衍生出来的。很多企业的项目都是采用这种方式来进行管理。下面这张图涵盖了这种方式的各种分支设计：
这个模型基本能满足企业项目开发过程中遇到的各种代码版本管理的需求，下面尝试着把这种模型分解给大家讲讲：
咬住青山不放松
在上面的图中，大家可以看到有两个分支的名字被加粗了：master 和 develop，这两个是分支当中的中流砥柱。
#### master
这是新建一个 GIT repository 之后的第一个分支。在这个模型中，master 分支代表的是当前产品线上的版本，它的最后一个 commit 可能是已经上线了，或者已经经过 QA/PD/PO 千万次折磨、分分钟可以上线的功能。换句话说，这条分支要做到 随时都可以上线的！要是谁把一个开发了一般的功能提交到这个版本上去，有可能会被 PO 拉去祭天的！所以如果有严格的权限管理的话，一般会把这个分支给锁起来，有且仅有上线的同事才有权限动它！
另外 master 的每次上线都会打一个 tag，表明版本号是多少
develop
一般灵长类动物都敬畏祭天这样的操作，所以我们需要开辟一篇新天地来大有作为。为了和大部队保持一致，develop 的分支是基于 master 创建出来的
C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git branch
* master
C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git checkout -b develop
Switched to a new branch ‘develop’
C:\githome\github\gitdou (develop) (gitdou@0.1.0)
λ git show-branch -a –no-name
* [develop] add httpUtil.js
! [master] add httpUtil.js
! [origin/HEAD] add httpUtil.js
! [origin/master] add httpUtil.js
—-
最后的 git show-branch -a –no-name 命令的输出可以看到 develop 的分支是基于 master 创建出来的
如果项目不是特别大，版本管理也比较简单，那么 master 跟 develop 这两个分支就基本够用了
文体两开花
当项目稍微大一些的时候，会遇到各种各样的版本管理需求，但不一定每一种你都需要，当需要的时候可以再建立这些分支，比如有 features, release, hotfix
features
第一种情况比较常见，项目有很多同事并行开发，比如分了多模块给多个小组进行开发，如果各个模块都往 develop 分支上面丢，那么基本没办法做持续集成 (Continue Integration) 的操作。虽然最后集成的时候各模块一定会和谐相处的，但是在开发过程当中，不一定每一个 commit 都是向模块兼容，所以最好能每个模块都自行在一个旮旯捣腾，等最好确定能相亲相爱了，大家再杵到一块去。
这是我们可以基于模块创建各种 feature 分支，有关开发人员就在相应的分支上进行开发就行，等到各个功能分支基本完成了，我们再把这些分支 merge 到 develop 上面去
如果有了 feature 分支，那么 develop 分支基本就成了集成分支了
release
前面说了 master 分支代表着当前产品线上的版本，分分钟可以上线部署而不会导致祭天这种结局的。但这有些项目或团队有这样的情况，产品上线前要先部署到准产品线上去玩，内测一周左右，确定完全没有问题了再上到产品线上去。在内测的这一周，如果发现了有问题了，赶紧从 develop 分支进行修复，再上到准产品线来验证。如果我们用 master 分支来进行准产品线的部署，在内测的这一周发现问题，而这时我们的产品线上有紧急问题要 fix，那么我们就无法直接拿 master 分支上线，这就做不到我们之前的承诺: master 分分钟可以上线而不用祭天
所以我们可以创建一个 release 的分支来进行准产品线的部署和问题修复，知道确认完全没有问题了，我们再同步到 master 分支去上线
hotfix
做系统的哪可能没有 bug！当产品线上无辜出现 bug 的时候，我们要去哪个分支做修复呢？
master：显然不合适，产品线上由于设计或者考虑不周出现 bug 一般是不用祭天的，但如果因为这样，在 master 上面一通乱改，那就有可能要祭天了
release：这个是给下一个版本用的呢。如果是上一个版本的话，那新增的修改就破坏了原来版本号的意义了，比如原来分支叫 release-1.0.1, 那么加了这个版本还叫这个名字吗？
developer: 如果还有一些其它正在开发的功能，那一会上线的时候就会连带这个也稍上去了！
feature：这就有点扯远了
看来上面这 4 种分支都不大合适，那就来款新的，就叫 hotfix. hotfix 分支是从 master 分支直接创建出来的，用来做一些产品线上紧急的代码修复，或者临时添加的小功能。开发人员直接在这个分支上进行开发，功能完成后直接上到 master 分支再上线。
记得每次 hotfix 上线后，要把功能同步回 developer，再到各 feature 的分支上
以上就是关于 这款 成功的代码分支管理模型的讲解，基本上能满足大部分企业大部分项目的代码版本管理的需求！后面会介绍另外一块代码分支管理模型，是指我们公司的一种管理的方式，下回见！