概要
代码版本管理的规范文档,包括定义项目在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,提交