代码分支及版本管理规范

目的

为了规范代码库分支管理 和 版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。

适用范围

适用于公司所有项目和产品

Git 分支管理

根据gitflow简化。代码库将包括 master、develop、hotfix、feature分支，hotfix 分支的命名规则分别为：hotfix-。feature分支的命名可以使用除master，develop，release-，hotfix-*之外的任何名称。

各分支使用办法说明如下：

• master分支

master分支是主分支，主分支是所有开发活动的核心分支。master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。

• develop分支

develop分支是保存当前最新开发成果的分支。当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。

• hotfix分支
  使用规范：
  1. 可以从master分支派生
  2. 必须合并回master分支和develop分支
  3. 分支命名惯例：hotfix-*
     当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
• feature分支
  使用规范：
  1. 可以从develop分支发起feature分支
  2. 代码必须合并回develop分支
  3. feature分支的命名可以使用除master，develop，release-，hotfix-之外的任何名称。
     feature分支通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉。

版本号管理

• 版本号命名规则
  版本号的格式：v<主版本号>.<副版本号>.<发布号>
• 主版本号
  涉及系统架构或重大调整，主版本号加1；副版本号、发布号重新置0；
• 副版本号
  1. 增加新的业务功能，副版本号加1；发布号重新置0；
  2. 若副版本号累加至超过20时，采用主版本号进位制，主版本号加1，副版本号、发布号重新置0；
• 发布号
  1. 新增加hotfix时，则发布号加1;
  2. 若发布号累加至超过20时，采用副版本号进位制，副版本号加1，发布号重新置0；