GIT分支版本管理

???紵

　　目前常用的git分支管理实践有三种，即单主干（Trunk-Based development），GitHub Flow与GIT Flow三种。
　　TBD与SVN类似。开发和修复均在trunk上进行，按照周期打出Tag。发布首选Tag，如Tag不满足需求，则从trunk上打包发布。
　　GitHub属于双分支体系，一个是Master，一个是开发分支，master提供生产系统的发布，开发分支用于开发提交；任何修改、开发、功能都在从Master分支拉出的新分支进行，新分支代码完成通过测试和代码审查后，合并入master部署发布。
　　早期的OA发布是一种变体的GitHub，即所有开发人员共用develop分支，test系统由develop打包，测试完成后合并至master。图示如下：

　　OA开发是一个长期的较长版本发布周期的持续集成、随时发布的项目。GitHub并不适合。而另外一种Git分支管理即Git Flow概念的核心则是版本发布，适用于持续集成、随时发布的项目。原生的Git Flow包括五种分支，master\hotfix\release\develop\feature；develop上为下一个版本将要发布的内容；当一个新功能需要开发时，从develop上新建feature分支，开发完成后合并至develop，删除feature；当需要发布时，从develop拉出release分支，在release上打包部署测试，需修复时，直接在release上提交，修复后再次打包部署测试；当release上通过测试后，将修复合并至develop和master，生产则从master打包。
　　我们所采用的变体的GitFLow图示如下：

　　正如《Git 分支管理最佳实践》一文中所述的“每个开发团队都应该根据团队自身和项目的特点来选择最适合的分支实践”、“首先是项目的版本发布周期。如果发布周期较长，则 git-flow 是最好的选择。git-flow 可以很好地解决新功能开发、版本发布、生产系统维护等问题；如果发布周期较短，则 TBD 和 GitHub flow 都是不错的选择。GitHub flow 的特色在于集成了 pull request 和代码审查。”。我们对Git flow进行了变体。将feature与develop合并为develop，只采用git flow的四个概念，即master hostfixes,release和develop。
各个分支作用
　　Master分支 ：仅用于正式环境发布重大版本 （体现在正式环境）
　　Hotfixes分支：仅用于正式环境版本发布后修复正式环境BUG（当bug修复完成需合并至develop（或者release分支）程序员不应该去合并master分支当bug解决完毕后并且测试人员测试认可后才可以合并至master分支上。
　　Release 分支：预发布分支,当确定预发布时间后打包预发布版本，打包后在预发布版本上测试测试后问题将在预发布分支上解决测试完全没有问题后合并至master 及develop分支上（体现在oarelease环境）
　　Develop分支：日常开发分支，日常新功能开发在此分支上但其他分支所做的操作最终都会合并在此分支上（体现在oatest环境）
整体发布步骤：
　　1.项目经理确定发布新版本时间，确定后在Release 分支上打出tag标签确定版本。
　　2.测试人员根据release版本的功能验证，及测试，测试出现问题后提bug，并附带版本
　　3.开发人员分配到bug后切换Release 分支上修复bug，只修复bug提交
　　4测试人员根据jira提交情况在Release 分支上进行更新并且验证新版本bug
　　5.当验证完毕后，将release分支合并至master分支及Develop分支。
　　6.正式环境打包更新
异常发布步骤：
　　当正式环境出现重大bug后需更新正式环境
　　发现重大缺陷，
　　在Hotfixes分支上解决bug，当解决完后需要将代码合并此时会出现两种情况
　　⑴．当项目处于整体发布时需要将Hotfixes合并至Release 分支上。
　　⑵．当项目不处于整体发布阶段将Hotfixes合并至Develop分支。
　　以上是固化的Git flow。但在实践中hotfixes较少使用，且随着代码的稳定，flow显得臃肿和难于理解。在随着项目团队的进一步缩小和代码的逐渐稳定，我们又将四分支flow修正为三分支flow，即develop,master，release。对Master上的修复采用直接提交并合并至release和develop的方式。如下图：