git分支管理总结

git分支管理

分支含义

**

master

**
用于保存官方发布历史，与线上的版本一致。要确保任何时候从master分支都可以拿到处于可发布状态的代码。

一个工程只有一个master分支，创建Git工程后自动创建，生命周期为永久。

跟master分支打交道的分支有dev分支、hotfix分支：

测试通过后，需要将dev分支合并到master分支。
线上出现bug时需要从master分支迁出代码到hotfix分支上进行晋级修复。
线上紧急修复后，需要将hotfix分支合并回master分支。
发布成功后，需要在master分支上打Tag（记录里程碑），标记官方发布的版本号。

版本号的命名规则

命名规则：vx.y.z[.h]

x：大版本号，有产品架构升级发布时升位。
y：中版本号，一般功能迭代发布时升位。
z：小版本号，增加新功能点或功能优化改进时升位。有迭代计划内hotfix时升位。
h：小版本号，迭代计划外的hotfix时升位。

dev

是开发集成的分支，所有开发完成的代码提交到此分支。功能累积到一定程度或者周期性发布需要提测时，从此分支迁出代码到release分支，进行测试。要确保任何时候都可以从dev分支拿到最新开发进展的代码。

一个工程只有一个dev分支，最初创建，生命周期为永久。

跟dev分支打交道的分支有release分支、hotfix分支、feature分支：

功能开发开始时，从dev分支迁出代码到feature分支进行开发。
提测时，dev分支迁出代码到release分支（将需要测试的feature合并到该release上进行测试）。
release分支测试通过后，将release分支合并回dev分支。
线上紧急修复后，将hotfix分支合并到dev分支。

release

是测试分支，用于测试某个待发布的版本。从dev分支迁出代码到release分支，冻结代码（除了修改bug），进行测试。测试通过后合并到dev分支，正式发布。

release分支整合同一个迭代多个feature进行提测，保证每个迭代统一回归测试。

一个工程不建议有多个release分支，每个release分支建议在上一迭代稳定后，基于稳定的dev分支开出。

release分支的生命周期不是永久的，最初起源于dev分支，最终归于dev分支。

提测时，创建一个release分支；测试通过、合并到dev分支后，删除该分支（可暂留若干个迭代）。

跟release分支打交道的分支有dev分支、feature分支、hotfix分支：

提测时，从dev分支迁出代码、创建一个release分支，然后把待测试的feature分支合并到当前release分支上。
相同迭代下有新的feature提测，在有当前迭代release分支时不再开新的release分，将该feature合并到需要提测的release分支上一并测试。
release分支测试通过后，将release分支合并到dev分支，同时将dev分支合并回master分支。
测试、开发修改bug，都是在release分支上进行。在devops上发布时推荐构建release分支，版本号在devops上会更清晰。

release分支命名规则：release/迭代x.y.z

feature

是各个功能的开发分支，开发完成后合并到dev分支。

feature分支使得多个人可以并行开发，互不干扰。

一个工程有多个feature分支，一个feature一个分支。

feature分支的生命周期不是永久的，最初起源于dev分支，最终归于release分支。

开始开发一个新功能时，由开发自己创建一个feature分支；功能开发完成、合并到release分支后，开发者自己删除该分支（可暂留若干个迭代）。

跟feature分支打交道的分支有dev分支、release分支：

从dev分支迁出代码创建一个feature分支进行功能开发。
功能需要提测时，如果功能为当前迭代功能，合并到当前迭代release分支上提测；如果功能为之后迭代的功能，先在feature分支上自测，待上一迭代发布后，再开出新迭代的release分支进行合并提测。
feature分支的命名规则：feature/迭代x.y.z-新特性关键字

hotfix

用于紧急修复线上的bug。

hotfix分支使得线上bug的紧急修复，与待发布版本的测试、以及新版本的开发活动可以并行，互不干扰。

一个工程有多个hotfix分支，一次hotfix创建一个分支。

hotfix分支的生命周期不是永久的，最初起源于master分支，最终归于master和dev分支。

提出hotfix时，创建一个hotfix分支；bug修改完成、合并回master分支以及dev分支后，“配管”删除该分支。

跟hotfix分支打交道的分支有master分支、dev分支：

需要紧急修复线上bug时，从master分支的某个Tag（一般是最新的）迁出代码、创建一个hotfix分支。
bug修改完成、测试通过后，合并到dev分支，同时“配管”将该hotfix分支合并回master分支。
hotfix分支的命名规则：

迭代规划内hotfix：hotfix/迭代x.y.z-hotfix关键字
迭代规划外hotfix：hotfix/迭代x.y.z.h[-hotfix关键字]
操作流程
克隆远程仓库
仓库管理员创建仓库，开发人员从 Gitlab 中克隆远程仓库

命令示例:

git clone <仓库地址>
提交并推送初始版本
仓库管理员提交代码初始版本到 master 分支，并推送至 Gitlab 系统

仓库管理员在 Gitlab 系统中设置 master 分支为 Protected 分支(保护分支)Protected 分支不允许 dever 推送代码，但 Master 可以推送代码

命令示例:

提交本地修改:

git add .
git commit –m “提交日志”

推送 master 分支:

git push origin/master
创建开发分支
仓库管理员在 master 分支上创建 dev分支(开发分支)，并推送至 Gitlab 系统 master

master 分支与 dev 分支一样，有且仅有一个

命令示例:

从 master 分支上创建 dev 分支:

git checkout –b dev master

推送 dev 分支:

git push origin/dev
开发新功能
开发人员在 dev 分支上实现新功能，包括:新特性与 Bug 修复
命令示例:

切换到 dev 分支:

git checkout dev

提交本地修改:

git add .
git commit –m “提交日志”

推送 dev 分支:

git push origin/dev
若存在多个新特性可以并行开发，则仓库管理员可创建一个或多个 feature 分支(特性分支)，命名规范:feature/迭代x.y.z-新特性关键字，例如:feature/0.1.0-pages
当新特性开发完毕后，仓库管理员需将 feature 分支合并到发布的对应的 release 分支，最后需删除 feature 分支

命令示例:

从 dev 分支上创建 feature 分支:

git checkout –b feature/0.1.0-pages dev

合并 feature 分支到 release 分支:

git checkout release/0.1.0
git merge --no-ff feature

删除本地 feature 分支:

git branch –d feature/0.1.0-pages

删除远程 feature 分支:

git push origin/feature/0.1.0-pages
什么时候需考虑使用 feature 分支?

开发一个独立的新特性(完成时，需合并到 release 分支)
技术研究与尝试(若失败，可随时删除 feature 分支)
提前实现下一个版本需要开发的特性(可不在本次迭代中发布)
准备发布新版本
确认各个 feature 分支上的功能是否开发完毕。
首个完成的 feature 的开发者从 dev 分支创建 release 分支(发布分支)，命名规则:release/迭代x.y.z，例如:release/0.1.0。
完成开发的 feature 分支均向当前迭代的 release 分支上合并。
每个 feature 开发完成通知测试可对 release 分支进行测试。
测试通过在 release 上修改版本号至当前迭代版本。
命令示例:

从 dev 分支上创建 release 分支:

git checkout –b release/0.1.0 dev
集成&冒烟测试
对 release 分支进行冒烟测试。
从 release 分支上检出所有代码并搭建集成测试环境。
邮件通知测试，对 release 分支进行测试。
修复待发布版本中的 Bug
开发人员在 release 分支上修复测试人员提交给自己的 Bug。

只允许在 release 分支上修复 Bug，不允许提交任何新特性。

命令示例:

切换到 release 分支:

git checkout release/0.1.0

提交本地修改:

git add .
git commit –m “提交日志”

推送 release 分支:

git push origin/release/0.1.0
发布新版本
将 release 分支同时合并到 master 分支与 dev 分支。
修改 master 分支上的 Maven 快照版为发布版(去掉 SNAPSHOT 后缀)。
添加发布日志(confluence上创建发布日志页面)。
在 master 分支上创建标签，命名规则:vx.y.z[.h]，例如:v0.1.0。
删除 release 分支（可以暂存若干迭代）。
命令示例:

合并 release 分支到 master 分支:

git checkout dev
git merge --no-ff release/0.1.0

合并 release 分支到 dev 分支:

git checkout master
git merge --no-ff dev

在 master 分支上创建标签:

git tag v0.1.0

删除本地 release 分支:

git branch –d release/0.1.0

删除远程 release 分支:

git push origin/release/0.1.0
修复线上 Bug
第一步:创建 hotfix 分支
从 master 分支某个 tag 上创建一个 hotfix 分支(热修复分支)，命名规则:hotfix/迭代x.y.z-hotfix关键字，例如:hotfix/0.1.1-i18n
开发人员完成 Bug 修复
通知测试对 hotfix 分支进行测试
命令示例:

从某个标签上创建 hotfix 分支:

git branch hotfix/0.1.1-i18n v0.1.0
第二步:测试验证 Bug 是否已修复
第三步:创建标签并发布新版本
通过测试进行冒烟测试
将 hotfix 分支同时合并到 master 与 dev 分支
第四步:发布新版本
添加发布日志(confluence上创建发布日志页面)
在 master 分支上创建标签
删除 hotfix 分支
命令示例:

合并 hotfix 分支到 master 分支:

git checkout master
git merge --no-ff hotfix/0.1.1-i18n

合并 hotfix 分支到 dev 分支:

git checkout dev
git merge --no-ff hotfix/0.1.1-i18n

在 master 分支上创建标签:

git checkout master
git tag v0.1.1

删除本地 hotfix 分支:

git branch –d hotfix/0.1.1-i18n

删除远程 hotfix 分支:

git push origin/hotfix/0.1.1-i18n
若无法将 hotfix 分支合并到 master 与 dev 分支时，应该如何发布?
比如:现在 master 分支已经发布了 2.0.0 版本(代码结构发生了很大的变化)，但线上发现了一个 0.1.1 版 本的 Bug，当修改了 Bug后，是无法再合并到 master 与 dev 分支的，仓库管理员需完成以下任务:

在0.1.1版本标签上创建 hotfix 分支，命名规则:hotfix/迭代x.y.z.h[-hotfix关键字]，例如:hotfix/0.1.1.1
直接在 hotfix 分支上创建标签。
删除 hotfix 分支(分支删除了，只要标签还在，版本就可以找得回来)。
如果当前迭代存在正在提测的 release 分支手动修改 release 分支中的代码(在后续发布时再合并到 master 分支中)。
如果不存在正在提测的 release 分支，视产品需求创建 feature（下个迭代发布）或者 hotfix（直接发布）分支进行bug修复。
定制化项目
当需要对某项目进行定制化时，可从源项目的 Git 仓库 fork 出一个新的 Git 仓库:

当 fork 后，对 repo1 做出的任何修改，都不会影响到 repo2 在 repo2 中修复了 Bug，可通过 Merge Request 的方式提交给 repo1 在 repo2 中可随时拉取 repo1 中的提交，但 repo1 不能拉取 repo2 中的提交

Gitlab 角色与项目角色对应关系
Owner(拥有者) Git 管理员
创建 Git 仓库
Master(管理员) 仓库管理员
检查 Git 分支规范
Developer(开发者) 开发人员
管理项目分支
Reporter(报告者) 测试人员
成员管理
Guest(观察者) 其他人员
管理标签
Git Commit Message 规范
Commit Message 格式
Commit Message 格式

<类型>(<功能点>): <主题>
<空行>
<内容>
<空行>
<尾注>
注意：

标点符号均使用英语符号（因为通过插件生成的是英语符号）
具体的文字内容使用中文，无需强硬要求使用全英文编写 Commit Message
类型
本次提交的类型，目前可以使用：

功能 - 实现的新功能
修复 - 漏洞的修复
重构 - 对已有功能的修改（无法分类为功能及修复但又涉及代码逻辑变更的提交类型，如把方法换了一个类）
文档 - 对文档及注释的新增和修改
格式化 - 对代码进行格式化（如修改缩进、删除多余空行和规整 Import）
测试 - 单元测试的代码
框架 - 在框架中新增或修改独立配置文件、升级依赖的版本和修改项目自身版本
Merge - 分支合并、代码审查时需要审查者手动合并分支并解决冲突
初始化 - 第一次提交
若提交代码时遇到了无法归类的情况，应暂缓提交，组织讨论并按需更新本文档。

功能点（可选）
本次提交涉及的功能点

应尽量填写功能点，方便进行检索

具体内容没有要求，但应与历史提交中的统一

一次提交不应涉及多个功能点，若提交了抽象层面的代码导致多个功能点变更，可以标注抽象层面的信息作为功能点

主题
用清晰又简洁的短语描述此次提交的主要内容，

格式：动词 + 名词

主题中无需重复提及“功能点”

当类型为“修复”时，主题的内容描述修复的问题内容，不提及解决方案

另一种方法为描述解决方案，但不提及错误内容
两种方法没有好坏之分，这里只是约定使用同一种
切忌仅使用动词（如“update”、“更新”和“完成功能”等）来作为主题

第一行举例：
“功能(第三方人群): 实现人群文件上传对象存储”
“修复(入库): 修复报表字段不对应导致程序崩溃”
“初始化: 初始化项目”
“框架: 更新依赖 commons-io 的版本至 x.x.x”
错误样例 “功能(第三方人群): 实现第三方人群的 CRUD”（重复提及功能点）
错误样例 “修复(第三方人群): 人群名称的国际化应该是 i18n.xxx”（1.主题没有动词，2.描述解决方案而不是错误内容）
内容（可选）
通过一至多行描述“主题”无法清楚描述的内容，如特殊逻辑和简要思路等。

无论一行或多行都以横杠（-）开始,遵循 Markdown 的格式

但不建议在“修复”类型的提交中描述具体解决方案，这应该写在 Jira、 Confluence 或代码注释中。

尾注（可选）
尾注可以标注本次提交涉及的 Jira ID，在正确配置的情况下 GitLab 将更新对应 Jira 的状态并将本次提交关联在 Jira 上

格式：Fixes|Resolves|Closes:

其他注意事项
当一次提交涉及的内容较少并可以用主题完全概括时，可仅填写第一行作为 Commit Message
当一次提交涉及多个类型或多个主题时，应该对提交进行拆分

总结

禁止直接在 dev 或者 master 上面修改代码并提交到和仓库。
其他分支合并到 dev/master 需要新建 mr。
feature 分支都是从 dev 检出。格式参考：feature/迭代x.y.z-新特性关键字。
release 分支由当前迭代的 feature 开发中的第一个提测的开发人员创建。格式参考：release/迭代x.y.z。
hotfix 分支只能来自于最新的 master分支或者历史的 tag。
hotfix 测试完成之后：
如果来自于 master，需要将 hotfix 合并到 master 和 dev 分支。格式参考：hotfix/迭代x.y.z-hotfix关键字
如果来自于历史 tag 版本，需要即使hotfix打一个新的 tag 之后; 同样的修改要在master上再做一次, 然后再合并 dev 中。格式参考：hotfix/迭代x.y.z.h[-hotfix关键字]
当前迭代的 feature 提测都需要合并到对应版本的 release 分支. 合入之后删除 feature 分支. 之后bug修复等都基于 release 分支操作。
每一个 release 分支提测，都对应测试环境一个单独的部署目录。
禁止将提测 feature 或者 release 分支代码部署在测试环境当前正在使用的目录，也就是环境软链的项目目录。
跨版本的 feature 可以提前开发.特殊情况可以跨版本提测，比如说功能完全独立的情况. 之后等待上一个版本发布之后, 再创建一个对应版本的 release 分支. 合并分支后需要进行回归和整体测试。
每一次解决代码冲突,需要和冲突文件开发人员进行沟通和讨论, 禁止独自解决并合入其他分支。
发布当天的产品的 bug 修复不需创建 hotfix，仍然属于当前版本范畴。
发布完成且验证之后 , release 分支将合入 master 和 dev。 并打上 tag，之后会删除对应的 release 分支。
代码提交时要遵守 Git Commit Message 规范。
计算端新环境部署（非发布）：
使用最新版本部署：
从master检出release-<日志>-x.y.z.h-<环境>
//TODO
使用历史tag部署：
//TODO