（GIT）代码分支管理策略
一、我们采用的管理策略（分支开发主干发布）
1. 主分支（master），用于发布，每次发布时打一个（tag），不做任何开发使用
拉取源：无
合并目标：无
修改：不允许
生命周期：持续
2. 开发分支（develop），每次有新需求时，从（master）拉取创建一个新分支，测试完成后合并到（master），合并后需要重新测试
拉取源：master
合并目标：master
修改：允许
生命周期：合并后删除（上线稳定运行后再删除）
3. 测试/预发布分支（release），开发到某一阶段时，创建一个（release）分支提供测试，如果测试期间，对应的开发分支（develop）有修改，则需要同步到（release）分支，或者直接使用开发分支（develop）覆盖（release）分支
拉取源：develop
合并目标：无
修改：不允许
生命周期：测试完成后删除
4. 问题修改分支（hotfix），用于修复线上问题，从对应线上版本的（tag）拉取，修改并测试完成后（merge）到（master），在（master）测试完成后，从（master）发布，同时打一个新的（tag）
拉取源：tag
合并目标：master
修改：允许
生命周期：测试完成后删除（上线稳定运行后再删除）
二、GIT操作规范
1. 代码修改前，必须先从对应分支PULL最新代码
2. 完成代码编写后，COMMIT到本地仓库，建议经常COMMIT到本地仓库，以防丢失或者被覆盖
3. PULL最新代码，如果需要MERGE，原则上不允许覆盖别人提交的代码，如果存在冲突的情况，如果不能百分百确定可以覆盖，需要与相关开发人员共同MERGE
4. PUSH本地代码到远程仓库
5. 代码开发阶段，不建议频繁PUSH，如果是公共代码或者被依赖的代码，完成测试后即可PUSH
6. 对于多人同时开发相同文件，如果存在开发中但是必须提交的情况，可以先REVERT，修改后COMMIT，然后再从LOCAL HISTORY中将被还原的代码拉取出来
三、两种主流的管理策略
1. 主干开发分支发布
得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。 这是业界采用较多的模式。
稳定分支上的有些修改，比如缺陷修复，需要合并到主干， 但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。
比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。【此段摘自于网络 http://thinkernel.bokee.com/4518935.html 】
2. 分支开发主干发布
得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。
从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。
主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
【此段摘自于网络 http://thinkernel.bokee.com/4518935.html 】
四、A successful Git branching model
简单描述：
1.存在一条主分支（master）。所有用户可见的正式版本，都从master发布。主分支作为稳定的唯一代码库，不做任何开发使用。
拉取源：无需。
合并目标：无需。
修改：不允许。
生命期：持续。
2.存在一条开发分支（develop）。这个分支维护了当前开发中代码的主线，始终保持代码新于master。持续集成、最新隔夜版本的生成等都是基于这个分支。由于当前版本迭代较快，开发分支只提供拉取，不进行实际开发。
拉取源：master。
合并目标：无需。
修改：不允许。
生命期：持续。
3.临时性多个功能分支（feature）。从develop拉取。开发feature完成，merge回develop。为了降低对其他feature的影响，一般在提测前merge回develop分支。
拉取源：develop。
合并目标：develop。
修改：允许。
生命期：合并后删除。
4.临时性多个预发布（测试）分支（release），用于QA测试。从develop拉取，测试完成merge回master和develop。如果测试期间，有其他版本合并入master，需要同步到release版本，并进行测试。
拉取源：develop。
合并目标：master & develop。
修改：允许。
生命期：合并后删除。
5. 临时性多个bug修复分支（fixbug），用于修复线上问题。从master拉取，修复并测试完成merge回master和develop。如果修复期间，有其他版本合并入master ，需要同步到fixbug版本，并进行测试。
拉取源：master。
合并目标：master，develop。
修改：允许。
生命期：合并后删除。
参考资料：
