# 分支管理
* * *
软件的版本控制以及分支管理贯穿于整个软件产品的生命周期，日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。本分支管理和版本控制规范主要分为3个部分，即`分支管理规范`、`版本号规范`、`需求与代码关联`。其中，将阐述不同的分支管理模型，以及它们的优缺点和使用的场景；描述版本号控制方式——语义化版本；以及将需求与代码管理的必要性等。
## 分支管理规范
目前比较流行的分支管理模型有三个，即`GitFlow`、`GitLabFlow`、`GitHubFlow`。下面将介绍这三种分支模型的原理，使用场景和优缺点等。
### GitFlow
`GitFlow`是最早诞生并得到广泛应用的一种工作流程。
该模型中存在两种长期分支：`master`和`develop`。`master`中存放对外发布的版本，只有稳定的发布版本才会合并到`master`中。`develop`用于日常开发，存放最新的开发版本。
也存在三种临时分支：`feature`,`hotfix`,`release`。
* `feature`分支是为了开发某个特定功能，从`develop`分支中切出，开发完成后合并到`develop`分支中。
* `hotfix`分支是修复发布后发现的Bug的分支，从`master`分支中切出，修补完成后再合并到`master`和`develop`分支。
* `release`分支指发布稳定版本前使用的预发布分支，从`develop`分支中切出，预发布完成后，合并到`develop`和`master`分支中。
优点：
* `feature`分支使开发代码隔离，可以独立的完成开发、构建、测试
* `feature`分支开发周期长于`release`时，可避免未完成的`feature`进入生产环境
缺点：
* 无法支持持续发布。
* 过于复杂的分支管理，加重了开发者的负担，使开发者不能专注开发。
### GitHubFlow
`GitHubFlow`分支模型只存在一个`master`主分支，日常开发都合并至`master`，永远保持其为最新的代码且随时可发布的。
* 在需要添加或修改代码时， 基于`master`创建分支，提交修改。
* 创建`Pull Request`，所有人讨论和审查你的代码。
* 然后部署到生产环境中进行验证。
* 待验证通过后合并到`master`分支中。
这个分支模型的优势在于简洁易理解，将`master`作为核心的分支，代码更新持续集成至`master`上。根据目前收集到的反应来看，得到了更多的好评，认为`GitHubFlow`分支模型更加轻便快捷。
### GitLabFlow
`GitLabFlow`是`GitFlow`和`GitHubFlow`的结合，它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
该模型采取上游优先的原则，即只存在一个`master`主分支，它是所以分支的上游。只有上游分支采纳的变动才能应用到其他分支。
* 对于持续发布的项目，建议在`master`之外再建立对应的环境分支，如预生产环境`pre-production`，生产环境`production`。
* 对于版本发布的项目，建议基于`master`创建稳定版本对应的分支，如`stable-1`，`stable-2`。
### 分支命名规约
| 前缀 | 含义 |
| --- | --- |
| master | 主分支，可用的、稳定的、可直接发布的版本 |
| develop | 开发主分支，最新的代码分支 |
| feature-\*\* | 功能开发分支 |
| bugfix-\*\* | 未发布bug修复分支 |
| release-\*\* | 预发布分支 |
| hotfix-\*\* | 已发布bug修复分支 |
### 提交命名规约
除了分支的名称需要规范，提交的命名也同样如此。
格式为：\[操作类型\]操作对象名称，如\[ADD\]readme，代表增加了readme描述文件。
常见的操作类型有：
* \[IML\] 实现正在开发的功能
* \[UPDATE\] 更新或改善已经实现的功能
* \[FIX\] 修复BUG
* \[REF\] 重构一个功能，对功能重写
* \[ADD\] 添加实现新功能
* \[DEL\] 删除不需要的文件
## 版本号规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
1.主版本号：当你做了不兼容的 API 修改。
2.次版本号：当你做了向下兼容的功能性新增。
3.修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
