项目上用的branch管理和Git是有些问题的。
多个branch的优劣：
优点：易于团队合作、易于功能开发、方便release、开发不用经常切分支、冲突少、测试少。
缺点：管理成本高 + 维护成本高：提交+合并+验证、fixbug。
因为互联网项目迭代快，branch维护管理特别频繁，这些实际情况。 现象是branch特别多、管理成本高（A）、经常需要7个team按照顺序集中合并代码，而且是每组指定一个人（B），并且冲突特别多（C）。查看历史记录总是对不上修改的作者（D）。
这些问题背后是git使用、branch管理的问题。
A问题：branch提测线太多，branch维护累、合并、测试累。因为每个组自己出测试包，可能1-3个特性。解决方法是使用统一的Dev开发线，feature开发自测完合并到dev线。
B问题：因为开发的deadline导致，一定按顺序合并的原因是使用了大量的merge，导致代码commit 向前的依赖不定，易产生冲突。这个人又不一定是feature的开发者，难于保证不出问题。
解决方法是：feature开发完，由开发者自己rebase到dev线，时间是deadline之前，因为commit都是前向依赖，增量开发不宜冲突。
C问题：原因是之前大量使用merge导致，三方merge导致commit是三方合并，没有明确的前向依赖。后面所有开人员强制使用rebase。
D问题：merge了之前的代码，新的merge commit 自动曾加了当前的作者。
branch管理思路：
Master主线用于relase稳定线：hotpatch的补丁branch提交验证通过，打到这个线上。同时自动cherry-pick到开发线。
Devbranch所有模块的开发线：feature开发自测完成，rebase到这个线，进行测试验证提测，在这个上CI、AUTOTEST
Feature branch：开发新功能线，codereview、自测在这个线上完成。
附上新的branch规划和Git日常常用使用命令使用方法。
