# 基于 GitFlow 的版本控制
# 背景
在多组员，多项目等环境进行协同工作时，如果没有统一规范、统一流程，则会导致额外的工作量。所以要减少版本冲突，减轻不必要的工作，就需要规范化的工作流程，来避免版本和分支管理混乱，无法快速响应客户变更和bugfix。
# 编写的目的
- 通过规范化的流程，使得产品、开发与测试等各个部门更高效的协同工作。
- 规范化的流程也是建立持续交付的基础，而持续交付也是微服务的基础。
# 前提
# 提交的准则
- 除了源码相关的文件，其他build产生的东西（如：obj文件夹，bin 文件夹等），均不能提交进入源码仓库，添加到.gitignore文件中忽略掉。
- 尽量减少二进制文件的提交，文档尽量以 markdown 编写，以便可以显示变化记录。
- 撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。
- 要严格按照我们指定的流程切换到指定分支，开发相应的功能。
# 版本号管理
本文采用以下的版本号方案：主版本号 . 次版本号 . 修正版本号
- 主版本号，正式版本从1开始，测试版本可以从0开始，当出现软件架构、设计思想改变或大量重写，主版本号+1，也代表不再向后兼容。
- 次版本号，当有较大增加或变更了功能，涉及数据库的改动等次版本号+1。在敏捷开发中，一般1-2周更新一次。
- 修正版本号，当修复软件bug或者微小业务逻辑调整不该懂数据库时，修正版本号+1。
- 在数据库中，也应该记录数据结构的版本号，运行时应该检查数据结构和软件的版本号是否一致。
# 运行环境说明
- 生产环境，对应用户使用的最新版本。
- UAT 环境，对应用户测试版本，组织用户验收和内测的版本。
- SIT 环境，对应内部测试版本，公司内部测试人员测试的版本，测试通过后提交到 UAT 环境。
- 开发环境，对应开发人员对接联调的版本。
# GitFlow 工作流程图
# master
- master 生产分支，是用户当前版本所在的分支，对应发布到生产环境和 UAT 环境。
- 你不能直接在 master 分支上提交，可以通过 release 和 hotfix 分支合并。
- 每个版本的发布都是对应一个带有版本 tag 的提交。
- 该分支应该自动编译部署到 UAT 环境。
# develop
- develop 开发分支，是当前发开的最新进度，该分支应该自动编译部署到开发环境。
- 由各个成员的 feature 分支合并而来。
# feature
- feature 功能分支，用来开发一个新的功能。
- 每个 feature 分支，应该是由成员通过最新的 develop 分支创建而来。
- 成员在完成分支并自测通过后，将确保代码可以编译成功，然后合并到develop（可以通过 git hooks 来确保）。
# release
- release 发布分支，当 develop 版本的准备提测时应生成该分支，该分支应该自动编译部署到 SIT 环境。
- 该分支由 develop 分支创建而来，只能用来修复测试中的 bug。创建该分支，会确定本次发布版本的 tag ，当首次提交 SIT 时，次版本号+1。
- SIT 测试无误后，应该合并到 develop 和 master ，转到 UAT 测试步骤。
- 在 UAT 中，如果也出现了需要修改的地方，应该创建新的 release 分支，修正版本号+1。
# hotfix
- hotfix 补丁分支，当我们在生产环境发现 bug 时通过该分支来快速响应，该分支应该自动编译部署到 UAT 环境。
- 由 master 分支创建，完成后合并回 master 和 develop 分支。创建新的 hotfix 分支时，修正版本号+1
# 环境-版本对应关系
| 环境 | 分支 | 备注 |
|---|---|---|
| 生产环境 | mater | 手动发布 |
| UAT 环境 | mater + hotfix | 自动编译发布 |
| SIT 环境 | release | 测试指定版本发布 |
| 开发环境 | develop | 自动编译发布 |
# 怎么做
我们按照的windows 版本的 git 自带 gitflow 工作流程
git flow init '初始化 gitflow
git flow feature start *** '创建feature分支
git flow feature finish ***
git flow release start 1.1.5 '创建release分支
git flow release finish 1.1.5
git flow hotfix start *** '创建hotfix分支
git flow hotfix finish ***