Git版本管理规范

仓库

分组命名规范

分组(Group)是以两级来进行管理。首先以所属产品域的大类，建立一级分组，然后在下面建立二级分组。

仓库命名规范

项目统一放在二级分组下，编码结构：项目描述 + 备注，以’-’为分隔。

• 项目描述：采用语义化的项目名，结构建议为用户群+功能描述。
• 备注：可以是终端，如网页端(web，wap等)、手机(mobile)、和其他一些智能设备（如收银机、电视等）、等；也可以是代码架构的描述；等。

仓库权限

由开发组leader或研发负责人在分组下根据仓库命名创建项目代码仓库。团队内成员，建议在一级分组上分配；外包人员，根据开发所涉及的具体项目逐个分配对应的二级分组权限。

角色	描述	权限范围
Owner	项目所有者	可以设置项目的访问权限-Visibility Level、删除项目、迁移项目、管理组成员；开发组leader设置该角色。
Maintainer	项目维护者	可以创建项目、添加 tag 、保护分支、添加项目成员、编辑项目；研发负责人设置该角色。
Developer	开发人员	可以clone、开发、commit、push。研发人员设置该角色。
Reporter	测试人员	可以克隆代码，不能提交。测试人员、产品经理设置该角色。
Guest	访客	可以创建issue、发表评论、不能读写版本库。

分支

分支命名规范

名称	命名规则	说明
master	-	稳定版本
develop	dev/develop	最新版本
release	release/创建时间（YYYYMMDD）	发布新版本
feature	feature/功能点名称	实现新特性
hotfix	hotfix/禅道bug号	修复线上紧急Bug
bugfix	bugfix/禅道bug号	修复普通Bug

创建项目时，会针对不同环境创建几个常用分支：

• master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。研发负责人在 Gitlab 系统中设置 master 分支为protectd 分支(保护分支)。protected 分支不允许 Developer 推送代码，但 Maintainer可以推送代码。
• develop：开发分支，该分支记录相对稳定的版本，所有的 feature 分支和 hotfix分支都从该分支创建。研发负责人在 Gitlab 系统中设置 develop分支为protectd 分支(保护分支)。
• release：发布分支，用于代码上线准备，该分支从 develop 分支创建，创建之后由测试人员发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，修复完成自测没问题后，在上线之前，需要合并该 release 分支到 master 分支，同时需要再合并该分支到 develop 分支。
  平时开发工作中，会根据需要由开发人员创建几类临时分支：
• feature：特性（功能）分支，用于开发某个特定的功能，该分支从 develop 分支创建，不同的功能创建不同的功能分支，开发完成自测没问题后，需要合并该分支到 develop 分支，之后删除该分支。
• bugfix：bug 修复分支，用于修复某个普通的 bug，该分支从 develop 分支创建，修复完成自测没问题后，需要合并该分支到 develop 分支，之后删除该分支。
• hotfix：热修复分支，用于修复某个紧急的 bug，该分支只有在紧急情况下使用，该分支从 master 分支创建，用于紧急修复线上的 bug，修复完成自测没问题后，需要合并该分支到 master 分支，以便上线，同时需要再合并该分支到 develop 分支，之后删除该分支。

版本号说明

版本号为三位以‘.’分割的数字组成。第一个数字是主版本。第二个数字是次版本。第三个数字是补丁版本(hotfix 类的更新)。

• 主版本：含有破坏性更新、大调整等。 例如：1.0.0 > 2.0.0。
• 次版本：增加新功能特性。例如：2.0.0 > 2.1.0。
• 补丁版本：修复问题等。例如：2.1.0 > 2.1.1。

代码提交

用户设置

设置提交代码的用户名称和邮箱为本人工号和工作邮箱。

代码提交规范

提交规范一般包括：标题（类型、精简总结）、内容、备注 。其中精简总结和类型是必填的，其余都是选填。

标题

名称	命名规则
feat	新功能
fix	修复bug
docs	文档变更
style	代码格式优化
refactor	重构代码
perf	性能、页面优化
test	增加测试用例、单元测试
revert	回退版本
build	打包
chore	构建过程或辅助工具的变动

必填的精简总结是非常重要的，一般是是总结概括的文字。要让人一眼就能看出来主要提交了什么，是添加了功能还是解决了问题，同时它也是大多数git管理工具默认展示的一行。需在第二行加上，禅道需求/任务/bug的id。如：
–fix: 修复了页面卡顿的bug。
–story: 1024

内容

内容主要填写详细的改动内容。如果精简总结写的比较完美，内容不写也是没关系。如果更改确实很多，并且时间充裕的话，把本次提交内容的实现、需求以及背景都填写，是很负责的做法。比如：
–fix: 修复了页面卡顿的bug
–story: 123

在网络不好时，渲染页面的接口被重复调用。
此次更改了页面接口的逻辑判定，在并发请求中……采用了……所以……。

备注

备注主要作用就是有一些额外的hook补充，比如提交记录之后，自动触发代码联动编译，或者自动生成git提交的通知。

Git仓库迁移

在二级分组下创建新空白代码仓

不用生成readme文件

克隆原始代码仓

本地创建新目录，执行如下命令（注意替换成对应的仓库地址）
git clone --bare git@gitlab.old.com:group/xxxService.git

推送到新仓库

执行步骤二后本地目录会生成一个名为 xxxService.git 的目录，进入此目录，执行如下命令：
cd xxxService.git
git push –-mirror https://gitlab.new.com/test/xxxService.git

修改已有代码仓库地址

完成以上3个步，代码仓迁移即已完成。由于大多数项目之前已在本地clone并进行开发，需要修改已有代码的远程仓库地址。进入已有代码目录，执行如下命令：
git remote set-url origin https://gitlab.new.com/test/xxxService.git