一般来说，程序人员开发应用，会有4个环境，生产，预发，测试，开发；
第一种功能版版本本控制：
一般有三个环境，对应三个不同的分支；
需求开发流程：
第一步：从master拉取功能分支，开发相应的需求，（功能分支要按照一定的命名规则去取，不要乱取）；
第二步：在功能分支上开发自己的需求，需求开发完成之后，通过merge 合并到test分支，在test环境完成自测，自测完成之后，提交测试，由测试相关同学完成相应的需求测试；
第三步：在测试的过程中，测试提出相关的bug,bug在功能分支上进行修复，修复完成之后，通过cherry-pick 合并到test,测试完成之后；
第四步：达到上线条件之后，代码通过merge合并到preview, 测试同学在preview 上验证，如果在验证中存在bug,会在功能分支上进行修复，修复完成之后，会通过cherry-pick依次合并到test, preview;
第五步：preview 验证无问题之后，会通过merge 合到线上，线上发现新的问题，则可以在功能分支开发，通过cherry-pick 合到test， preview,通过merge合到master上，到这里，就完成了一次上线；
线上bug修复流程：
第一步：发现线上环境有bug,拉取修复bug的分支hotfixed；
第二步：在hotfixed上修改bug,修复完成后，合到test，preview，由测试人员回归；
第三步：确定没有问题之后，讲hotfixed 合并到master,到这里，也就完成了线上bug修复的流程；
优点：1.sourcetree 的分支图表会很清晰，不混乱；
2.各个功能分支上线不受影响；
缺点：1.多个cherry-pick，有时候会出现漏合并；（解决可以对多个cherry-pick 进行合并）
2.上线的代码，只在线上回归的时候验证，如果操作不当，可能会把一些冲突带上去；
3.合代码的人不会了解开发的具体功能，即使代码review,也不一定能发现问题；
第二种双周迭代版版本控制：
需求开发流程：
第一步：从master拉取功能分支，开发相应的需求，可以提到develop上进行自测，后端也可以测试；
第二步：开发完成之后，到提测时间，在git上提交一个merge-request 到test上，部署test,测试人员介入测试， 发现bug之后，在功能分支上修改bug, 修改完成之后，通过merge-request 到 test上；
第三步：测试完成，没有问题，在test上切出一个release分支，进行预发的测试，发现bug之后，在功能分支修改bug,修改完成之后，通过merge-request到test，到release;
第四步：release测试没有问题之后，达到上线条件，在release 打tag 并标注上线具体内容，发版上线；
线上bug修复流程：
第一步：发现线上环境有bug,拉取修复bug的分支hotfixed；
第二步：在hotfixed上修改bug,修复完成后，合到devlop 自己验证，最后合到test由测试人员验证，最后由开发人员基于test拉出一个release 分支，上到预发环境，验证没有问题之后，在release 上打tag上线；
第三步：确定没有问题之后，讲hotfixed 合并到master，test，到这里就完成了上线；
优点：上线前的代码经过多个环境测试，很大避免了由于代码合并失误造成的问题；
缺点：上线流程复杂，及时上线上面可能不是那么适用；
优化：可以加一个testweekly的分支，来解决小版本上线；
职场小白south Joe，望各位大神批评指正，祝大家学习愉快！
