（GIT）代码分⽀管理策略
⼀、我们采⽤的管理策略（分⽀开发主⼲发布）
1. 主分⽀（master），⽤于发布，每次发布时打⼀个（tag），不做任何开发使⽤
拉取源：⽆
合并⽬标：⽆
修改：不允许
⽣命周期：持续
2. 开发分⽀（develop），每次有新需求时，从（master）拉取创建⼀个新分⽀，测试完成后合并到（master），合并后需要重新测试
拉取源：master
合并⽬标：master
修改：允许
⽣命周期：合并后删除（上线稳定运⾏后再删除）
3. 测试/预发布分⽀（relea），开发到某⼀阶段时，创建⼀个（relea）分⽀提供测试，如果测试期间，对应的开发分⽀（develop）有修改，则需要同步到（relea）分⽀，或者直接使⽤开发分⽀（develop）覆盖（relea）分⽀
拉取源：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修改和现有功能的完善，⽽不会再增加新特性。新特性会继续在主⼲上开发。当稳定分⽀上发⽣的修改积累到⼀定程度以后，就会有⼀次发布。发布的时候会在稳定分⽀上再分出来⼀个 relea分⽀。以6.x为例，就会有6.0,6.1,6.2…等发布分⽀。
【此段摘⾃于⽹络
thinkerne圆通老板
/4518935.html 】
2. 分⽀开发主⼲发布
得到⼀个稳定版本后，拉男人的肩膀
出先锋分⽀，在分⽀上开发新功能，在主⼲上进⾏修修补补。当先锋分⽀通过⼀定的测试之后，合并到主⼲。可以同时有多个先锋分⽀，不同的功能可以拉不同的分⽀，不同发布时间点⽽⼜要同时开发的内容必须在不同的分⽀上。
从发布的⾓度讲，更推荐将肯定⼀起发布的内容放在相同的先锋分⽀上。
主⼲上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分⽀上进⾏。⽽且每个bug和新功能都有不同的开发分⽀，完全分离。⽽对主⼲上的每⼀次发布都做⼀个标签⽽不是分⽀。分⽀上的开发和测试完毕以后才合并到主⼲。
这种发布⽅法的好处是每次发布的内容调整起来⽐较容易。如果某个新功能或者bug在下⼀次发布之前⽆法完成，就不可能合并到主⼲，也就不会影响其他变更的发布。另外，每个分⽀的⽣命期⽐较短，唯⼀长期存在的就是主⼲，这样每次合并的风险很⼩。每次发布之前，只要⽐较主⼲上的最新版本和上aabb词语大全
⼀次发布的版本就能够知道这次发布的⽂件范围了。
【此段摘⾃于⽹络 /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.临时性多个预发布（测试）分⽀（relea），⽤于QA测试。从develop拉取，测试完成merge回master和develop。如果测试期间，有其他版本合并⼊master，需要同步到relea版本，并进⾏测试。
拉取源：develop。
合并⽬标：master & develop。
修改：允许。
⽣命期：合并后删除。
5. 临时性多个bug修复分⽀（fixbug），⽤于修复线上问题。从master拉取，修复并测试完成merge回master和develop。如果修复期间，有其他版本合并⼊master ，需要同步到fixbug版本，并进⾏测试。
拉取源：master。
合并⽬标：master，develop。
修改：允许。
⽣命期：合并后删除。
参考资料：
