开发流程与版本管理规范（上）

一.版本号规则

如非特殊说明，所有产品的版本号将遵循 主版本.次版本.BuildNumber 的规则。

• 主版本号：发布重大更新时增加
• 次版本号：发布新功能点时增加
• build number: 打包的编号， 日常更新，bug 修复， 功能优化

例如 2.1.34， 2 是 主版本号， 1为次版本号， 34 是 build number. 主版本号变化时次版本号清零，但是 build number 不清零，一直累加。2.1.34 的下个版本号是 3.0.35 、 2.2.35 或者 2.1.35 之一。

二.代码库版本管理

公司的代码库使用 git 管理版本。 不熟悉 git 同事请先阅读 git 的 相关文档: https://gitee.com/progit/

下面描述公司的 git 的 使用规范。

主要分支

代码库中包含两个主要的分钟

1. master
2. develop

origin/master 的最新版本应与生产环境当前版本一致， master 分支上的所有历史版本与线上生产环境的历史版本一一对应。

origin/develop 分支是开发集成的版本。

当 develop 分支的当前版本达到稳定状态，意味着可以向生产环境发布了。这时 develop 分支需要通过某种方式合并到 master 分支并且打上发布版本号 tag。 后面我们将详细说明这个过程。因此每当有修改合并到 master 分支， 意味着我们产生了一个新的版本号。这个规则必须严格遵守，matser 分支发生改变时将触发持续集成工具和脚本自动打包， 推送到生产环境。

支持分支

除了 master 和 develop 两个主要分支, 我们还使用多种支持分支来协作日常开发。与主要分支不同，这些分支可能生命周期比较短，一个支持分支合并到主要分支后将被移除。支持分支主要分三种：

1. 功能特性的分支
2. 发布分支
3. 紧急修复分支

每种分支都有不同的作用并且遵循不同的 fork 、合并和命名规则。从 git 角度看，各种分支并不存在特殊性， 只是我们依据我们的开发流程需要产生的一种使用规范。

功能特性分支

起源分支： develop

合并对象分支: develop

命名规则： 除了 master, develop, release-*, or hotfix-* 之外没有特殊限制

功能特性分支用来开发新功能，可能这个功能是下一个版本将要分布的，也可能会在更后期的版本中发布的。当我们开始开发一个新功能时， 这个功能将在哪个版本中发布可能是未知的。这个功能特性开发完成后会合并到 develop 分支然后并删除分支；或者如果开发到某个阶段产品设计上认为这个功能可以被砍掉， 那这个分支将会被丢弃。

//开始开发 myFeature 功能时，我们在 develop 分支的基础上创建一个 myFeature 的新分支
git checkout -b myFeature develop

// 提交代码, 注意： 提交信息一定要写清楚
git commit

// 将分支推送到 git 服务器
git push --set-upstream origin myFeature

如上所述， 一个功能特性分支一般经过：创建=>提交=>推送 的过程。 注意: commit 时一定要写清楚修改了什么， 测试同事才好针对性的测试，建议每做一个小修改就提交一次，这样 commit message 才能准确描述所做的修改， 而不是等到整个功能都做完，推送之前再一次性提交。

push 到服务器后，请到内部的 gitlab 上提交 merge request。收到 merge request 的同事需对代码进行审查， 确定没有明显的 bug 后再合并到 develop 分支。这时这个功能特性分支的生命周期就结束了，可以删除。

// 删除分支
git branch -d myFeature

发布分支

起源分支： develop

合并对象分支: develop 或 master

命名规则： release-*

发布分支是为发布到生成环境做准备的。当所有需要发布的功能特性都已合并到develop 分支， 并且经过测试到达相对稳定的状态后， 我们在 develop 分支的基础上创建一个新的 release-* 分支。这个 release- 分支 不应该包含那些不在此次发布计划中的功能，因此那些功能相对应的分支必须等 release- 分支创建之后再合并到 develop.

release 分支创建时将分配一个版本号（此处应有脚本来管理版本号）， 如 release-1.038, 并且生成版本日志。

git checkout -b release-1.2.56 develop

此分支在正式发布到正式环境之前，可能会有一些 bug 修复， 但是新功能的代码不允许提交到此分支。

// 在 release 分支基础上创建用于 bug 修改的分支, 分支的命名规则应该为 release-*_bug*
git checkout -b release-1.2.56_bug1 release-1.2.56

git commit

git push --set-upstream origin release-1.2.56_bug1

bug fix 的分支推送到服务器，经审核后合并到 release-* 分支。直到 bug 修复到了允许发布到生成环境的状态时需要将此分支分别合并到 master 分支和 develop 分支.

1. 将 release 分支合并到 master // 切换到 master 分支 git checkout master // 将 release 分支合并到 master 分支 git merge --no-ff release-1.2.56 // master 分支打上 tag git tag -a 1.2.56
2. 将 release 分支合并到 develop // 切换到 master 分支 git checkout develop // 将 release 分支合并到 develop 分支 git merge --no-ff release-1.2.56

将 release 分支合并到 develop 分支后， develop 分支也有了bug fix 的代码。 这时 release-1.2.56 不再需要了，可以被删除

git branch -d  release-1.2.56