GIT仓库使用规范_git仓库规范方案

概要

代码版本管理的规范文档，包括定义项目在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仓库操作示意图

初始化

注：命名

• master：线上分支
• Dev：开发分支
• v0.0：迭代分支

开发与迭代

注：命名

• Dev：开发分支
• v0.0：迭代分支
• rebaseV1：合并用分支

流程

1. 从DEV环境切出开发开发迭代分支
2. 开发结束后，切换至dev分支，拉取最新代码
3. 切换至v0.0，合并dev分支代码，解决冲突
4. 创建rebanse分支，合并commit内容
5. 切换至dev分支，合并rebanse分支，添加tag，并提交

上线

注：命名

• master：线上分支
• Dev：开发分支
• rebaseDev：合并用分支

流程

1. 创建rebase 分支
2. 切换至rebanse,合并commit
3. 切换至master,合并rebase，添加tag，并提交

线上修复

注：命名

• master：线上分支
• hotfix：修复分支
• Dev：开发分支
• rebaseMaster：主分支合并用分支
• rebaseDev：开发分支合并用分支

流程

1. 创建hotfix修复分支
2. 修复BUG后创建rebaseMaster
3. 切换至rebaseMaster分支，合并commit，提交至master
4. 合并dev开发分支内容，并解决冲突
5. 创建rebaseDev分支，合并commit
6. 切换至dev分支，合并rebaseDev，标记tag，提交