git-分支策略与版本管理

前言

本产品代码借鉴Git Flow分支策略，并基于该策略进行必要的调整和改进。

Git Flow分支策略普及

常见的分支策略有以下三种：GitFlow、GitHubFlow以及GitLabFlow。

Git Flow

GitFlow是这三种分支策略中最早出现的。

GitFlow通常包含五种类型的分支：Master分支、Develop分支、Feature分支、Release分支以及Hotfix分支。

• Master分支：主干分支，也是正式发布版本的分支，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许向Master分支直接提交代码（对应生产环境）。
• Develop分支：开发分支，用来集成测试最新合入的开发成果，包含要发布到下一个Release的代码（对应开发环境）。
• Feature分支：特性分支，通常从Develop分支拉出，每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。自测完成后，会将Feature分支的代码合并至Develop分支，进入下一个Release。
• Release分支：发布分支，发布新版本时，基于Develop分支创建，发布完成后，合并到Master和Develop分支（对应集成测试环境）。
• Hot fix分支：热修复分支，生产环境发现新Bug时创建的临时分支，问题验证通过后，合并到Master和Develop分支。

通常开发过程中新特性的开发过程如下：

从Develop分支拉取一条Feature分支，开发团队在Feature分支上进行新功能开发；开发完成后，将Feature分支合入到Develop分支，并进行开发环境的验证；开发环境验证完成，从Develop分支拉取一条Release分支，到测试环境进行SIT/UAT测试；测试无问题后，可将Develop分支合入Master分支，待发版时，直接将Master分支代码部署到生产环境。

可参考下图：

GitFlow的优点是每个分支都有明确的定义，严格按照GitFlow管理项目代码的话，很难出现代码混乱；其缺点是：如果特性分支过多的话很容易造成代码冲突，从而提高了合入的成本；由于每次提交都涉及多个分支，所以GitFlow也太不适合提交频率较高的项目。

本产品分支策略说明

在保留Git Flow分支策略的主分支master和develop的基础上，重新定义如下分支：

• master: 产品基线分支，该分支仅合并patch和develop分支代码，绝不允许在分支上进行开发
• develop: 产品主线开发分支，该分支仅合并patch和develop_xxx分支代码，绝不允许在分支上进行开发
• develop_xxx: 功能开发分支，该分支用于替代繁琐的feature分支，并以版本号作为尾缀标示该分支待开发功能所属版本，例如develop_v2.0.0表示产品v2.0.0所有新增功能的开发
• develop_xxx_patch??: 功能开发分支补丁，该分支用于替代繁琐的hotfix问题修复分支，并以版本号+patch[补丁号]作为尾缀标示所属版本的第几个补丁，例如develop_v2.0.0_patch01表示产品v2.0.0发布包在实际部署后出现的问题修复或功能补充优化等的第一个补丁

移除release待发布测试分支的概念，而是在相应develop（已合并功能开发分支代码）或develop_patch??分支上打标签并移交部署至测试环境待测试验证回归后合并至指定分支（一般默认为develop和master）

本产品版本管理

软件版本阶段说明

• Base版:  此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
• Alpha版:  此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
• Beta版:  该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
• RC版:  （Release   Candidate）该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
• Release版:  该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。

版本命名规范

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

版本号定修改规则：

• 主版本号(1)： 当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
• 子版本号(1)： 当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
• 阶段版本号(1)： 一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
• 日期版本号(051021): 用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
• 希腊字母版本号(beta): 此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

文件命名规范

文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。

本产品代码标签补充说明

无论是开发阶段完结、提交测试、版本发布，均需要在对应开发分支上打tag标签，标签的命名则使用以上描述的版本命名，例如2.0.0版本在8月17号开发完毕后提交测试，则标签命名为2.0.0.0817_beta，并附上必要描述，命令如下：

--新建标签并加注释
git tag '2.0.0.0817_beta' -m '2.0.0版本在8月17号开发完毕后提交测试'
--推送标签至远程库，将标签运用在所有关联分支上
git push --tags