概要
代码版本管理的规范文档，包括定义项目在Stash上的创建规范，版本号定义，Git中Branch的使用，以及多Branch，多版本的维护，版本管理的目的在于在多人，多版本，多阶段的开发环境下，既能保证尽可能的多线开发，又能保证线上版本的明确性和溯源。
版本管理
版本代表产品/项目的版本号，每一次的版本变更表示一次正式的发布。这里的版本和代码的版本并无任何关系，但是后续部分会说明如何利用Git的Branch和Tag功能去追踪某一个版本下的代码源文件。版本管理的原则如下
- 能够清晰的对外对内描述每一个版本的功能变更
- 能够回溯到之前的版本
- 能够方便追踪到某个版本下的所有源文件
- 能够同时维护多个版本
版本号定义
版本号由三部分数字组成，每部分数字英文句号连接：Major_Version_Number.Minor_Version_Number[.Revision_Number] ，每一次版本的变更代表一次对外发布
Major_Version_Number 代表大的milestone，通常是指大的功能模块的上线，或者架构调整
Minor_Version_Number 代表功能的增强，系统的局部优化
Revision_Number 代表bug修复和极小功能调整
非Mobile App：Revision_Number需要以YYMMDD00的格式出现，YYMMDD为时间戳，表示该次修复发布的时间，精确到天，00代表该天发布的第几个版本，以01开始，最高到99。
Mobile App：Revision_Number和Major_Version_Number以及Minor_Version_Number一样，为数字递增，和发布在应用商店上的版本保持一致
比如：1.2.14080203 表示基于1.2 的在2014年8月2日做的第三次发布。
利用Git进行产品和项目的多版本维护/发布
原则
Master（多模块情况下是{module_name}_master)上永远是线上的版本
每次Major Version 和 Minor Version的更新（产品/项目发布后）需要在该产品所用到的所有系统（不管此次更新有没有涉及此系统）上开一个Branch进行维护，Branch名称为版本号，但是不要加上Revision Number
每次Major Version， Minor Version， Revision的更新需要在该产品所用到的所有系统（不管此次更新有没有涉及此系统）的相应Branch中打上Tag，Tag名称为版本号
开发前需要明确哪些Repository属于这个产品/项目，哪些属于基础服务。
如果基础服务是以Jar包/Plugin形式打包在其他代码里，那需要用我们的本地Artifactory库来管理这些Jar包/Plugin，在代码的Maven/Ivy/Gradle 以及Grails的BuildConfig里面，会有这些依赖的版本描述，用来将基础服务和某个版本的产品/项目代码挂钩
commit内容规范（请务必在rebase时使用规范）
**格式 type-commit (如：fixed-安卓手机不兼容)
- feat/new：新功能（feature）
- fixed：修补bug
- docs：文档（documentation）
- style/css： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
GIT仓库操作示意图
初始化
masterdevv1.0初始化项目迭代开发masterdevv1.0
注：命名
- master：线上分支
- Dev：开发分支
- v0.0：迭代分支
开发与迭代
devv1.0rebaseV1.0建立开发分支开发结束建立rebase分支拉取并合并最新dev分支解决冲突合并commit并提交（tag）devv1.0rebaseV1.0
注：命名
- Dev：开发分支
- v0.0：迭代分支
- rebaseV1：合并用分支
流程
- 从DEV环境切出开发开发迭代分支
- 开发结束后，切换至dev分支，拉取最新代码
- 切换至v0.0，合并dev分支代码，解决冲突
- 创建rebanse分支，合并commit内容
- 切换至dev分支，合并rebanse分支，添加tag，并提交
上线
devrebaseDevmaster创建rebase合并commit并提交（标记tag）devrebaseDevmaster
注：命名
- master：线上分支
- Dev：开发分支
- rebaseDev：合并用分支
流程
- 创建rebase 分支
- 切换至rebanse,合并commit
- 切换至master,合并rebase，添加tag，并提交
线上修复
masterhotfixrebaseMasterdevrebaseDev建立修复分支测试完成创建rebase合并commit并提交（标记tag）合并dev并解决冲突创建rebase合并commit并提交masterhotfixrebaseMasterdevrebaseDev
注：命名
- master：线上分支
- hotfix：修复分支
- Dev：开发分支
- rebaseMaster：主分支合并用分支
- rebaseDev：开发分支合并用分支
流程
- 创建hotfix修复分支
- 修复BUG后创建rebaseMaster
- 切换至rebaseMaster分支，合并commit，提交至master
- 合并dev开发分支内容，并解决冲突
- 创建rebaseDev分支，合并commit
- 切换至dev分支，合并rebaseDev，标记tag，提交