Git 分支管理规范
V1.0.0
规范
Git 仓库申请流程
1. 开发主管向Git 管理员提交Git 仓库申请【邮件：发送给Git 管理员，抄送给项目经理，申请表可向Git
管理员获取】
2. Git 管理员审批开发主管的申请，审批以下具体信息：
a) 审批邮件是否抄送给项目经理
b) 申请的Git 仓库名称是否符合命名规范
3. 若审批通过，则Git 管理员完成以下任务：
a) 创建Git 仓库
b) 设置开发主管为Git 仓库的Master 角色（管理员，具有该Git 仓库的管理权限）
c) 将Git 仓库地址告知开发主管【邮件：发送给开发主管，抄送给项目经理】
4. 若审批不通过，则驳回申请【邮件：发送给开发主管，抄送给项目经理】
初始化Git 仓库
第一步：克隆远程仓库
开发主管从Gitlab 中克隆远程仓库
命令示例：
git clone <仓库地址>
第二步：提交并推送初始版本
开发主管提交代码初始版本到master 分支，并推送至Gitlab 系统
master
开发主管在Gitlab 系统中设置master 分支为Protectd 分支（保护分支）
Protected 分支不允许Developer 推送代码，但Master 可以推送代码
命令示例：
提交本地修改：
git add .
git commit –m “提交日志”
推送master 分支：
git push origin master
第三步：创建开发分支
开发主管在master 分支上创建develop 分支（开发分支），并推送至Gitlab 系统
master
develop
master 分支与develop 分支一样，有且仅有一个
命令示例：
从master 分支上创建develop 分支：
git checkout –b develop master
推送develop 分支：
git push origin develop
开发新功能
开发人员在develop 分支上实现新功能，包括：新特性与Bug 修复
master
develop
Feature + Bugfix
命令示例：
切换到develop 分支：
git checkout develop
提交本地修改：
git add .
git commit –m “提交日志”
推送develop 分支：
git push origin develop
若存在多个新特性可以并行开发，则开发主管可创建一个或多个feature 分支（特性分支），命名规范：
feature-分支创建日期-新特性关键字，例如：feature-20150508-i18n
develop
feature
当新特性开发完毕后，开发主管需将feature 分支合并到develop 分支，最后需删除feature 分支
命令示例：
从develop 分支上创建feature 分支：
git checkout –b feature-20150508-i18n develop
合并feature 分支到develop 分支：
git checkout develop
git merge --no-ff feature
删除本地feature 分支：
git branch –d feature-20150508-i18n
删除远程feature 分支：
git push origin :feature-20150508-i18n
什么时候需考虑使用feature 分支？
1. 开发一个独立的新特性（完成时，需合并到develop 分支）
2. 技术研究与尝试（若失败，可随时删除feature 分支）
3. 提前实现下一个版本需要开发的特性（可不在本次迭代中发布）
推荐使用feature 分支，但feature 分支的生命周期不能跨一次迭代
准备发布新版本
开发主管需完成以下任务：
1. 确认develop 分支上的功能是否开发完毕
2. 若开发完毕，则创建release 分支（发布分支），命名规则：release-分支创建日期-待发布版本号，例
如：release-20150508-v1.0.0
3. 首先在release 分支中升级Maven 版本号，例如：1.0.0-SNAPSHOT，然后修改version.ini 文件（便于在
部署时查看当前版本号），最后在release 分支上做一次提交
4. 通知测试主管可对release 分支进行测试【邮件：发送给测试经理，抄送给项目经理与团队成员】
master
develop
Feature + Bugfix
release
命令示例：
从develop 分支上创建release 分支：
git checkout –b release-20150508-v1.0.0 develop
修复待发布版本中的Bug
开发人员在release 分支上修复测试人员提交给自己的Bug
master
develop
Feature + Bugfix
release
Bugfix
只允许在release 分支上修复Bug，不允许提交任何新特性，开发主管需全程监管
命令示例：
切换到release 分支：
git checkout release-20150508-v1.0.0
提交本地修改：
git add .
git commit –m “提交日志”
推送release 分支：
git push origin release-20150508-v1.0.0
发布新版本
第一步：集成测试
测试主管需完成以下任务：
1. 从release 分支上检出所有代码并搭建集成测试环境
2. 安排测试人员，对release 分支进行集成测试
3. 通知开发主管当前版本已集成测试完毕【邮件：发送给开发主管，抄送给项目经理】
第二步：冒烟测试
开发主管需完成以下任务：
1. 将release 分支同时合并到master 分支与develop 分支
2. 邮件通知测试主管，对master 分支进行冒烟测试
第三步：发布新版本
开发主管需完成以下任务：
1. 修改master 分支上的Maven 快照版为发布版（去掉SNAPSHOT 后缀）
2. 添加发布日志（RELEASE.md）
3. 在master 分支上创建标签，命名规则：tag-日期-版本，例如：tag-20150508-v1.0.0
4. 删除release 分支
5. 打包并上传Maven 私服
6. 通知测试主管新版本已发布完毕【邮件：发送给测试主管，抄送给项目经理与Git 管理员，邮件格式
请找Git 管理员获取】
master
develop
Feature + Bugfix
release
Bugfix
1.0.0
命令示例：
合并release 分支到master 分支：
git checkout master
git merge --no-ff release-20150508-v1.0.0
合并release 分支到develop 分支：
git checkout develop
git merge --no-ff release-20150508-v1.0.0
在master 分支上创建标签：
git tag tag-20150508-v1.0.0
删除本地release 分支：
git branch –d release-20150508-v1.0.0
删除远程release 分支：
git push origin :release-20150508-v1.0.0
修复线上Bug
第一步：创建hotfix 分支
开发主管需完成以下任务：
1. 从master 分支某个tag 上创建一个hotfix 分支（热修复分支），命名规则：hotfix-分支创建日期-待
发布版本号，例如：hotfix-20150508-v1.0.1
2. 首先在hotfix 分支中升级Maven 版本号（例如：1.0.1-SNAPSHOT），然后修改version.ini 文件，最后在
hotfix 分支上做一次提交
3. 指导开发人员完成Bug 修复
4. 通知测试主管对hotfix 分支进行测试【邮件：发送给测试主管，抄送给项目经理】
master
hotfix
1.0.0
命令示例：
从某个标签上创建hotfix 分支：
git branch hotfix-20150508-v1.0.1 tag-20150508-v1.0.0
第二步：验证Bug 是否已修复
测试主管需完成以下任务：
1. 验证Bug 是否已修复
2. 通知开发主管Bug 已修复【邮件：发送给开发主管，抄送给项目经理】
第三步：创建标签并发布新版本
开发主管需完成以下任务：
1. 将hotfix 分支同时合并到master 与develop 分支
2. 通过测试主管进行冒烟测试
第四步：发布新版本
开发主管需完成以下任务：
1. 修改master 分支上的Maven 快照版为发布版（去掉SNAPSHOT 后缀）
2. 添加发布日志（RELEASE.md）
3. 在master 分支上创建标签
4. 删除hotfix 分支
5. 打包并上传Maven 私服
6. 通知测试主管新版本已发布完毕【邮件：发送给测试主管，抄送给项目经理与Git 管理员，邮件格式
请找Git 管理员获取】
master
develop
hotfix
1.0.0 1.0.1
Bugfix
命令示例：
合并hotfix 分支到master 分支：
git checkout master
git merge --no-ff hotfix-20150508-v1.0.1
合并hotfix 分支到develop 分支：
git checkout develop
git merge --no-ff hotfix-20150508-v1.0.1
在master 分支上创建标签：
git checkout master
git tag tag-20150508-v1.0.1
删除本地hotfix 分支：
git branch –d hotfix-20150508-v1.0.1
删除远程hotfix 分支：
git push origin :hotfix-20150508-v1.0.1
若无法将hotfix 分支合并到master 与develop 分支时，应该如何发布？
比如：现在master 分支已经发布了2.0.0 版本（代码结构发生了很大的变化），但线上发现了一个1.0.0 版
本的Bug，当修改了Bug 后，是无法再合并到master 与develop 分支的，开发主管需完成以下任务：
1. 直接在hotfix 分支上创建标签
2. 删除hotfix 分支（分支删除了，只要标签还在，版本就可以找得回来）
3. 手工修改develop 分支中的代码（在后续发布时再合并到master 分支中）
定制化项目
当需要对某项目进行定制化时，可从源项目的Git 仓库fork 出一个新的Git 仓库：
repo1 fork repo2
当fork 后，对repo1 做出的任何修改，都不会影响到repo2
在repo2 中修复了Bug，可通过Merge Request 的方式提交给repo1
在repo2 中可随时拉取repo1 中的提交，但repo1 不能拉取repo2 中的提交
附录
Maven 版本号命名规范
格式：Major.Minor.Micro
Major 版本 架构调整
Minor 版本 新特性
Micro 版本 Bug 修复、优化
Git 分支类型
分支 用途
master 分支（主分支） 稳定版本
develop 分支（开发分支） 最新版本
release 分支（发布分支） 发布新版本
hotfix 分支（热修复分支） 修复线上Bug
feature 分支（特性分支） 实现新特性
master
develop
Feature + Bugfix
release
Bugfix
hotfix
1.0.0 1.0.1
Bugfix
Gitlab 角色与项目角色对应关系
Gitlab 角色 项目角色
Owner（拥有者） Git 管理员
Master（管理员） 开发主管
Developer（开发者） 开发人员
Reporter（报告者） 测试人员
Guest（观察者） 其他人员
Git 管理员与开发主管的职责
Git 管理员 开发主管
1. 创建Git 仓库
2. 检查Git 分支规范
3. 维护Gitlab 系统
1. 管理项目成员
2. 管理分支
3. 管理标签