团队项目中的分支管理

提到分支管理我想大家脑子里闪现出来的一定是GIT对不对！（你要是SVN可就暴漏年龄了）

Git用法就不必多说了，你百度下一大堆，这里给大家分享下自己管理团队分支时的方法，欢迎补充~

1 固定分支开发（本地环境，测试环境，生产环境）

    假设项目初步建立完成，此时只有一个分支master，然后公司老板说，我们有钱了，给你再搞台服务器专门做测试用！

    那么这时你将分支从master上切出来了两个，test分支，dev分支。

    你告诉大家，以后我们发生产环境只能用master发布！发测试环境只能用test发布！ 自己在自己的dev分支上开发需求！

    如果需求很多，自己本地要针对每一个需求单独开个分支，比如：dev_imageBug, dev_itemNum,dev_log;

    你可以将三个分支都合并到test上面，测试通过的功能，再合并到master上发生产。

2 版本迭代

    一开始你用固定分支开发遇到了一个问题！   

    有一次明明测试通过的一个功能，和到了master上除了bug，这时产品对测试发了一通牢骚，测试对开发发了一通牢骚，开发对自己发了一通牢骚。

    固定分支的弊端暴露了出来——虽然功能分支（比如：dev_imageBug）合并到测试分支没有问题，但是测试的时候测得时test分支，而不是dev_imageBug分支。

    用dev_imageBug分支合并到master发布生产环境，这样的方法可以说是，把没有经过测试的分支（dev_imageBug）直接合并到了要发布生产环境的分支上了，危险，危险！

    因此团队成员头脑风暴了一番（emmm，我当时是问了其他团队学来的）后决定采用一种船新的模式。

    现在开始，我们切一个新的分支出来！叫做 feature_v1 ！我们这周要上线5个功能！ A B C D E F ! 这5个功能写好，并到feature_v1 上面发测试，

    测试通过之后，周四直接用feature_v1发布线上，没问题后，将feature_v1的代码合并到master上面！

    而且此时我们要再切出来一个分支叫feature_v2 ! 这个分支是用来下一周功能的开发的！循环往复直到开发到feature_v9999我们就此生圆满了

    perfact！ 测试的分支就是发布生产环境的分支，这样就避免了将没有经过测试的分支发到了线上！

    如果此时有bug需要可以在线上分支切出来一个feature_hotFix分支进行修复，应为bug不属于第二周的版本迭代。