代码分支管理规范
前言
了解 本文之前我们先了解基本又那些分支
常用分支
master 分支
这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
Develop分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
Hotfix分支
当我们在master发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
1. 申请
开发主管向仓库管理申请并抄送给项目经理， 通过后，会将开发主管设置为master权限，并发邮件把项目地址发给项目经理和开发主管
2. 初始化仓库
2.1 克隆远程仓库
// 开发主管从 Gitlab 中克隆远程仓库 // 命令示例: // git clone <仓库地址>
2.2 提交并推送初始版本
// 发主管提交代码初始版本到 master 分支，并推送至 Gitlab 系统
// Gitlab 系统中设置 master 分支为 Protectd 分支(保护分支)Protected 分支不允许 Developer 推送代码，但 Master 可以推送代码
// # 提交本地修改:
// git add .
// git commit –m “提交日志”
// # 推送 master 分支:
// git push origin master
2.3 创建开发分支
// 开发主管在 master 分支上创建 develop 分支(开发分支)，并推送至 Gitlab 系统 master
// master 分支与 develop 分支一样，有且仅有一个
```js
// # 从 master 分支上创建 develop 分支:
// git checkout –b develop master
// # 推送 develop 分支:
// git push origin develop
```
3. 开发新功能
3.1 关于develop分支
// 开发人员在 develop 分支上实现新功能，包括:新特性与 Bug 修复
// # 切换到 develop 分支:
// git checkout develop
// # 提交本地修改:
// git add .
// git commit –m “提交日志”
// # 推送 develop 分支:
// git push origin develop
3.2 关于 feature分支
// 若存在多个新特性可以并行开发，则开发主管可创建一个或多个 feature 分支(特性分支)，命名规范:feature-分支创建日期-新特性关键字，例如:feature-20190919-i18n
// 当新特性开发完毕后，开发主管需将 feature 分支合并到 develop 分支，最后需删除 feature 分支
```js
// # 从 develop 分支上创建 feature 分支:
// git checkout –b feature-20190919-i18n develop
// # 合并 feature 分支到 develop 分支: git checkout develop
// git merge --no-ff feature
// # 删除本地 feature 分支:
// git branch –d feature-20190919-i18n
// # 删除远程 feature 分支:
// git push origin :feature-20190919-i18n
```
3.3 什么时候需考虑使用 feature 分支?
// 开发一个独立的新特性(完成时，需合并到 develop 分支)
// 技术研究与尝试(若失败，可随时删除 feature 分支)
// 提前实现下一个版本需要开发的特性(可不在本次迭代中发布)
// 推荐使用 feature 分支，但 feature 分支的生命周期不能跨一次迭代
4. 准备发布新版本
4.1 准备工作
// 1. 确认 develop 分支上的功能是否开发完毕
// 2. 若开发完毕，则创建 release 分支(发布分支)，命名规则:release-分支创建日期-待发布版本号，例
// 如:release-20190919-v1.0.0
// 3. 首先在 release 分支中升级 Maven 版本号，例如:1.0.0-SNAPSHOT，然后修改 version.ini 文件(便于在
// 部署时查看当前版本号)，最后在 release 分支上做一次提交
// 4. 通知测试主管可对 release 分支进行测试【邮件:发送给测试经理，抄送给项目经理与团队成员】
4.2 修复待发布版本中的 Bug
// 开发人员在 release 分支上修复测试人员提交给自己的 Bug
// 只允许在 release 分支上修复 Bug，不允许提交任何新特性，开发主管需全程监管
```js
// # 切换到 release 分支:
// git checkout release-20190919-v1.0.0
// # 提交本地修改:
// git add .
// git commit –m “提交日志”
// # 推送 release 分支:
// git push origin release-20190919-v1.0.0
```
5. 发布新版本
5.1 集成测试
// 测试主管需完成以下任务:
// 从 release 分支上检出所有代码并搭建集成测试环境
// 安排测试人员，对 release 分支进行集成测试
// 通知开发主管当前版本已集成测试完毕【邮件:发送给开发主管，抄送给项目经理】
5.2 冒烟测试
// 开发主管需完成以下任务:
// 将 release 分支同时合并到 master 分支与 develop 分支
// 邮件通知测试主管，对 master 分支进行冒烟测试
5.3 发布新版本
// 开发主管需完成以下任务:
// 修改 master 分支上的 Maven 快照版为发布版(去掉 SNAPSHOT 后缀)
// 添加发布日志(RELEASE.md)
// 在 master 分支上创建标签，命名规则:tag-日期-版本，例如:tag-20190919-v1.0.0
// 删除 release 分支
// 打包并上传 Maven 私服
// 通知测试主管新版本已发布完毕【邮件:发送给测试主管，抄送给项目经理与 Git 管理员，邮件格式
// 请找 Git 管理员获取】
// # 合并 release 分支到 master 分支:
// git checkout master
// git merge --no-ff release-20190919-v1.0.0
// # 合并 release 分支到 develop 分支:
// git checkout develop
// git merge --no-ff release-20190919-v1.0.0
// # 在 master 分支上创建标签:
// git tag tag-20190919-v1.0.0
// # 删除本地 release 分支:
// git branch –d release-20190919-v1.0.0
// # 删除远程 release 分支:
// git push origin :release-20190919-v1.0.0
6. 修复线上bug
6.1 创建 hotfix 分支 开发主管需完成以下任务
// 从 master 分支某个 tag 上创建一个 hotfix 分支(热修复分支)，命名规则:hotfix-分支创建日期-待
// 发布版本号，例如:hotfix-20190919-v1.0.1
// 首先在 hotfix 分支中升级 Maven 版本号(例如:1.0.1-SNAPSHOT)，然后修改 version.ini 文件，最后在
// hotfix 分支上做一次提交
// 指导开发人员完成 Bug 修复
// 通知测试主管对 hotfix 分支进行测试【邮件:发送给测试主管，抄送给项目经理】
// # 从某个标签上创建 hotfix 分支:
// git branch hotfix-20190919-v1.0.1 tag-20190919-v1.0.0
6.2 验证 Bug 是否已修复测试主管需完成以下任务:
// 验证 Bug 是否已修复
// 通知开发主管 Bug 已修复【邮件:发送给开发主管，抄送给项目经理】
6.3 创建标签并发布新版本
// 开发主管需完成以下任务:
// 将 hotfix 分支同时合并到 master 与 develop 分支
// 通过测试主管进行冒烟测试
6.4 发布新版本
// 开发主管需完成以下任务:
// 修改 master 分支上的 Maven 快照版为发布版(去掉 SNAPSHOT 后缀)
// 添加发布日志(RELEASE.md)
// 在 master 分支上创建标签
// 删除 hotfix 分支
// 打包并上传 Maven 私服
// 通知测试主管新版本已发布完毕【邮件:发送给测试主管，抄送给项目经理与 Git 管理员，邮件格式
// 请找 Git 管理员获取】
```js
// # 合并 hotfix 分支到 master 分支:
// git checkout master
// git merge --no-ff hotfix-20190919-v1.0.1
// # 合并 hotfix 分支到 develop 分支:
// git checkout develop
// git merge --no-ff hotfix-20190919-v1.0.1
// # 在 master 分支上创建标签:
// git checkout master
// git tag tag-20190919-v1.0.1
// # 删除本地 hotfix 分支:
// git branch –d hotfix-20190919-v1.0.1
// # 删除远程 hotfix 分支:
// git push origin :hotfix-20190919-v1.0.1
```
6.5 若无法将 hotfix 分支合并到 master 与 develop 分支时，应该如何发布?
// 比如:现在 master 分支已经发布了 2.0.0 版本(代码结构发生了很大的变化)，但线上发现了一个 1.0.0 版 本的 Bug，当修改了 Bug后，是无法再合并到 master 与 develop 分支的，开发主管需完成以下任务:
// 直接在 hotfix 分支上创建标签
// 删除 hotfix 分支(分支删除了，只要标签还在，版本就可以找得回来)
// 手工修改 develop 分支中的代码(在后续发布时再合并到 master 分支中)
7. 定制化项目
// 当需要对某项目进行定制化时，可从源项目的 Git 仓库 fork 出一个新的 Git 仓库: // 当 fork 后，对 repo1 做出的任何修改，都不会影响到 repo2 // 在 repo2 中修复了 Bug，可通过 Merge Request 的方式提交给 repo1 // 在 repo2 中可随时拉取 repo1 中的提交，但 repo1 不能拉取 repo2 中的提交
8. 整理和规范说明
8.1 Maven 版本号命名规范
格式:Major.Minor.Micro
版本 说明
Major 版本 架构调整
Minor 版本 新特性
Micro 版本 Bug 修复、优化
8.2 Git 分支类型
分支 用途
develop 分支(开发分支)
最新版本
release 分支(发布分支)
发布新版本
hotfix 分支(热修复分支)
修复线上 Bug
feature 分支(特性分支)
实现新特性
# [git缓存]
常用git stash命令：
```js
（1）**git stash** save "save message" : 执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。
（2）**git stash list** ：查看stash了哪些存储
（3）**git stash show** ：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}
（4）**git stash show -p** : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show stash@{$num} -p ，比如第二个：git stash show stash@{1} -p
（5）**git stash apply** :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1}
（6）**git stash pop** ：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}
（7）**git stash drop** stash@{$num} ：丢弃stash@{$num}存储，从列表中删除这个存储
（8）`git stash clear ：`删除所有缓存的stash
