git基于分支的版本控制

小渣渣

基于分支的版本，就需要谈到下面这幅图，这幅图完美了诠释了配置管理过程中的全景。首先这个图是基于Git的模式进行编写的，但实际Git与Subversion在版本控制的管理理念上是想通的只是Git 确实在分支管理、分布式性能上比Subversion要有质的飞跃（但这不是本文的重点）。


在介绍这个图的原理之前，先要说说一般版本控制的两种不同的策略，一种是“先锋主干，稳定分支”，一种是“稳定主干，先锋分支”。顾名思义，就是稳定版本（生产版本），在主干上还是在分支上。在传统项目组使用VSS的情况下，很难说清楚到底属于那种模式，主要是VSS本身没有分支管理策略，所以，很多项目组最建立两个版本库（或者三个），分别对应生产环境、开发环境，当然这也属于变相的一种分支管理。但一般如果切换到Subversion或者Git作为版本控制工具的团队，多数都是使用稳定主干模式，即，主干（truck或master）对应稳定的生产环境，对于不同的发布分别打标签（tag）来标示出生产的版本。而我个人觉得稳定主干代码模式，应该是目前绝对的主流代码版本控制管理方案。而上面这幅图，就是标准的“稳定主干”管理模式。
master：对应Subversion就是truck。对应生产的版本，每一次发布就打一次标签（tag）。
release分支（也有称之为集成分支）：只要更新生产，都需要先合并到release分支（集成分支）。有点类似于目前项目组所称之为的“预生产”、“模拟环境”这个概念。
develop分支（开发分支或dev分支）：开发环境面对的环境。
feature分支（功能分支）：某些独立的功能，可以独立出单独的开发分支。此处主要是为了应对某些功能可能相对比较长时间才能更新，避免拖累版本而单独分出的分支。
hotfixes分支（bug修复分支）：此处的bug主要是生产bug。
介绍完主干和分支，我需要介绍一下这几个分支产生和合并的方向问题。
master是生产版本，主干仅接受两个分支进行合并，一个是release分支（集成分支），一个是hotfixes分支。其他任何分支都不能向生产分支进行合并。
release分支，在起初是与生产同时产生，就是和生产一模一样。他仅接受dev分支与之合并。换句话说，他并不接受功能分支或bugfixes分支直接合并过来。
dev分支，开发分支与集成分支一样，在某一个时点与生产环境是相同的。但是随着开发进度，会不断有新功能在dev分支上不断的产生。dev理论来说只接受两个分支的合并，一个是 hotfixes、一个是feature分支。
feature分支，开始与dev分支的某个时点（版本），功能分支最终会合并会dev分支。
以场景的方式简单介绍一下版本控制方式
假设某一个生产版本，分出各个分支（dev、hotfixes、release），这个时候，dev开始进行开发一共十个功能。当10个功能开发了8个功能的时候，测试组开始介入进行内部测试，配置管理员将dev分支通过持续集成工具（此处是另外一个议题在此不展开讨论）将dev分支，部署到dev环境中进行测试，然后不断发现bug不断修改。当测试验证发现，其中两个功能完全不能接受，需要重做，比如简易险投保，理赔回退，于是又从dev分出两个feature分支，分别对应简易险投保和理赔回退，并在dev分支上，也需要将对应的代码进行回退（此处为人工操作）。当测试团队发现dev分支测试没有问题的时候，达到uat的条件，于是配置管理员将dev分支合并到release分支上，再使用持续集成工具将此分支发布到预生产环境，交由用户进行测试，此时应跑一遍全量自动化测试用例，进行准生产全量回归测试。用户验证发现问题，开发人员修改dev分支，再合并到release分支（此处，原图中是在release分支中直接修改，我认为这样并不好，我建议开发人员只面对 dev分支），当验证release验证过程中，突发发现生成环境有一个严重bug需要立刻修复，那么就在hotfixes分支上紧急进行修改，验证无误后紧急上线。同时，hotfixes分支再与dev合并（此处多为手动，因为此时生产版本已经与dev版本相差很大，往往无法完成自动合并），然后dev再合并到release中，此时，用户、回归测试证无误后，希望上线，这时配置管理员release分支合并master，打标签，继续持续集成完成上线。有经历一段时间，理赔回退功能可能并不需要了，需要取消，那么理赔理赔退回feature分支删除。另一个功能简易投保开发完成，再次合并到dev分支中与下一次上线版本一同上线。
上面这个场景，基本囊括了日常开发过程中，常规开发、拆包、紧急更新等场景。