版本控制管理工具是作为程序猿开发的必备基础应用工具之一，之前笔者已经写过一篇文章，着重介绍了个人对gitrebase命令的理解和应用(?猛击观看^_^)；在此基础之上，本次笔者打算将git版本控制管理进行到底，再深入描述相关流程，用来记录我学习过程中的点点滴滴，也希望能够真正帮助到正在使用git工具的小伙伴。
1
场景解析
Git一些基本的命令在此就不做赘述，主要说下关于版本管理，项目真正上线后，如何管理各个分支，如果出现产线问题，如何有条不紊的来切版本解决bug，做hotfix分支管理。项目启动后，每个开发都会分到属于自己的一些开发需求，各自的需求有的是有交集的，有的是不相关的。前期开发需求时，一般都是基于一个共同的分支，来切各自的featrue分支来针对各自的需求来做开发。后期开发好后会merge到该分支，不相关的需求的开发决定着在merge过程中冲突很少或者没有冲突，有交集需求的代码merge就需要解决很多的冲突，解决完冲突后就可以将当前分支部署到相应环境进行测试。正常情况下，有三个主要的分支(好多公司都会采用dev-demo-stage-prod,这几套环境，本文暂时不考虑stage环境)，如下：
?master分支
当前分支为主分支，有的开发团队采用这个分支，有的不采用这个分支，本文说的采用是指是否从这个分支切上线分支或者基于这个分支打tag发布。
?demo分支
当前分支为demo环境部署分支，主要用来系统在开发阶段向产线部署过程中的一个重要demo测试环境。一般当期要上线的需求都在当前分支上。
?develop分支
当前分支为开发环境分支，一般超前开发的需求都merge到这个分支，用于开发人员的测试。
其实上面所说的三种分支都是体现在远程服务器上面的分支，相互协作开发的每个开发者都可以远程推送各种名称的分支，以及本地也可以切各种分支，最终效果是将开发者开发好的代码merge或者cherry-pick到上面的相关分支。版本控制管理的相关流程，笔者主要经历过两种，也就是接下来主要讲的，常用的模式以及推荐的模式。
2常用版本控制管理
1.常用版本控制管理
这个流程模式，是不需要采用master分支，当前发布版本是基于demo分支的一个代码提交点来切一个上线分支。有个问题在此着重说一下，因为本文不考虑stage环境，所以demo环境是项目部署到产线前的最后一道防线，为了保证上线的代码稳定性，我们在发布前三天是要将这个切出来的上线分支放在demo环境上进行测试以及回归测试的，来规避风险，确保稳定性。具体流程参照下图：
拆分流程如下:
?基于develop分支来切开发各自的本地feature开发分支；在当前基础上进行需求研发，自测，以及解决bug的自我研发过程；当需求开发结束，将会把相关代码pullrequest到develop分支上，再部署到dev环境，进行测试；
?确定当期发布需求，将已经提交到develop分支代码，cherry-pick或者merge，最终pullrequest到demo分支，进行demo环境部署测试；
?版本稳定后，基于demo分支切出上线分支，比如rt；一旦发现产线问题，基于rt分支来做hotfix，然后快速解决bug后，切出rt.01hotfix版本来紧急发布修复产线问题，最终将hotfix代码同步回demo分支。
3
推荐版本控制管理
1.推荐版本控制管理
当前版本控制管理是推荐的模式，GitHub
转载请注明：http://www.0431gb208.com/sjszjzl/814.html
