分支流转规范图

Git是一个十分优秀的版本控制工具，但仅仅依靠版本控制工具，还不能保证在多人协作的情况让项目的版本流转有条不紊，版本演进清晰整洁；还需要 Git工作流程规范的约束；目前广泛使用的工作流程是 Git Flow，但我个人认为它有很多不足之处，于是我就制定了一个新的规范，取名为 Git并行工作流程规范 ，为了清楚完整地描述 Git并行工作流程规范 ，我花了很多精力设计、撰写、绘图和制作动画，详见下文和相关文章！关于 Git并行工作流程规范 的设计思路请看 Git并行工作流程规范设计记录。

1. GitFlow的问题
2. Git并行工作流程的设计宗旨
3. 新概念的定义
4. 分支的分类
- 4.1. 按照生命周期来分
- 4.2. 按照作用来分
5. 按照流转环节来分
- 5.1. 包含关系
6. 分支的流转规范
7. 分支合并规范
8. 提交规范
- 8.1. 提交操作规范
- 8.2. 提交说明规范
  - 8.2.1. Angular提交说明规范
9. 相关技巧
- 9.1. 禁止快进式合并
- 9.2. 创建空分支（独立分支、孤儿分支）
- 9.3. 合并不相关的分支（没有共同历史的分支）
- 9.4. 只合分支并保持历史的线性
- 9.5. 用变基的方式pull
10. 相关文章

内容

1. GitFlow的问题

目前广泛使用的工作流程是 Git Flow，如下图所示：

GitFlow分支工作流程图

它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条；

但，我个人认为，它有许多不足之外，如下：

它需要维护两个相近的长期分支：Master 和 Develop；前者用于正式发布，后者用于日常开发；
每次完成预发布分支和修复分支时，都需要分别合并到 Master 和 Develop 这两个长期分支中；

GitFlow修复分支合并流程图
任务不独立；新任务的功能分支中有可能包含上个还未发布的任务的提交；
比如：按照 Git Flow，假设功能A 已经开发完成，并且已经被合并到了 Develop 分支；
这时又有功能B 需要开发，则会从 Develop 新建功能B 分支用于开发功能B ，则此时功能B 分支会包含功能A 分支的所有提交；
不支持多任务并行开发；
比如：按照 Git Flow，假设功能A 已经开发完成，并且已经走到了预发布阶段，则此时功能A 分支已经被合并到了 Develop 分支；
这时又有功能B 需要开发，则会从 Develop 新建功能B 分支用于开发功能B ，则此时功能B 分支会包含功能A 分支的所有提交；
如果这个时候发现功能A 有问题或者因种种原因，需要暂停功能A 的发布，但需要发布功能B ，这时就不好办了，因为功能B 分支中已经包含了功能A 的所有提交；

2. Git并行工作流程的设计宗旨

支持多任务并行开发；
避免同一分支需要分别向多个分支进行合并；
多个任务或多个功能之间独立、完整、互不干扰；
分支各司其职，演进清晰整洁；
分支的变更单元用提交节点表示；如：发布分支中的每一次提交都代表着一次发布，预发布分支的每一次提交都代表一次预发布，测试分支的每一次提交，都代表着一次转测；这样有助于各个分支演进清晰简洁；

3. 新概念的定义

为了方便下方或今后的表达，我需要定义以下概念：

临时性分支终将会被合并到长期分支中（除非弃用），如，开发完功能后，因转测，需要把功能分支合并到测试分支中，测试完后，测试分支又会被合并到预发布分支中，最后，预发布分支又会被合并到发布分支中；在这个过程中，功能分支依次被合并到了测试分支、预发布分支、发布分支；

像上面这样，分支在被其它分支合并的过程称为分支的流转；

分支A 被合并到分支B ，也称为 分支A 流转到了分支B；

分支A 流转到了分支B，分支B 又流转到了分支C ，像这样的过程称为 分支A 的连续流转，也称为 分支A 连续流转到了分支C；

连续流转过程中的每一个分支都称为该连续流转的一个流转环节，也称为该连续流转的一个 流转分支；

连续流转的所有流转环节的有序组合称为 流转链；

流转链中最初的流转环节（流转分支）又称为该流转链的 原始分支 或 初始环节；

流转链中最终的流转环节（流转分支）又称为该流转链的 终点分支 或 终点环节；

流转链中原始分支和终点分支之间的流转分支称为 中间分支 或 中间环节；

如果分支A 是基于分支B 创建的，即：分支A 是从分支B 创建的，则称分支B 是分支A 的 母分支；

4. 分支的分类

4.1. 按照生命周期来分

长期：伴随Git项目一直存在的分支；
临时：针对特定任务或目的而建的，且当完成任务或达到目的后需要被删除的分支；

4.2. 按照作用来分

发布：为存放已发布的、正式的版本而建的分支；
预发布：为即将正式发布的版本做试运行而建的分支；如果没有试运行阶段，则可以不设预发布分支；
功能：为实现一个或多个功能而开设的分支；
修复：为修复一个或多个问题而开设的分支；
协作：为实现多人协作而开设的分支；
合并：为合并多个分支而建的分支；
测试：为测试而建的分支；

5. 按照流转环节来分

流转分支
- 原始分支
- 中间分支
- 终点分支
母分支

5.1. 包含关系

按照作用来划分的类别与本规范中按照生命周期来划分的类别的包含关系如下：

长期
- 发布
临时
- 预发布
- 功能
- 修复
- 协作
- 合并
- 测试

即：

发布分支属于长期分支；
预发布分支、功能分支、修复分支、协作分支、合并分支、测试分支属于临时分支；

6. 分支的流转规范

根据上述的《Git并行工作流程的设计宗旨》，我为各类分支的流转设计了如下规范：

发布分支：该分支从预发布分支合并而来；如果没有预发布分支，则从测试分支合并而来；在将分支（如：预发布分支或测试分支）合并到发布分支前，需要确保该分支已经包含了发布分支上的所有版本；如果没有包含发布分支上的所有版本，则取消本次的分支流转，并重新转测或从原始分支重新发起流转；
预发布分支：该分支从测试分支合并而来；如果不需要，也可以不设预发布分支；
测试分支：该分支从被转测的分支合并而来；如：功能、修复、协作、合并；在转测前，需要确保被转测的分支已经包含了发布分支上的所有版本；即：如果被转测的分支在转测前，发布分支上有新的版本发布，且这些新的版本并没有包含在被转测的分支上，则需要先把发布分支上那些新的版本合并到被转测分支，然后才能转测，即：将被转测分支合并到测试分支上；
合并分支：该分支是对需要合并的多个分支进行合并而来的分支；
功能分支：基于发布分支创建；
修复分支：在没有不需要与被修复的问题一起转测的代码的情况下，应该在问题所在的流转链中的原始分支上直接修复问题，不必创建单独的修复分支（这是为了保证原始分支的完整性）；如果问题所在的流转链中的原始分支不存在或者原始分支中包含了不能与被修复的问题一起转测的代码，则应该基于问题所在的流转链中的终点分支创建修复分支，然后在该修复分支上修修复问题（这是为了保证多个任务或多个功能之间互不干扰）；当问题被修复完问题后，再将该修复分支合并到其对应的专门用于测试该修复问题的测试分支中，不应该把修复分支合并到该修复分支的母分支或者母分支对应的测试分支中；即：每个修复分支都有其对应的、专门的测试分支（这是为了保证测试分支和对应的被转测分支的代码的一致性，多个任务或多个功能之间独立、互不干扰）；
比如：
如果，被修复的问题是由功能A 导致的，且功能A分支上不包含不能与被修复的问题一起转测的代码，则应该直接在功能A分支中修复问题，不用创建专门的修复分支；
如果功能A 分支已经被删除了或者包含不能和被修复的问题一块转测的代码，则应该基于被修复问题所在的流转链的终点分支创建专门用于修复该问题的修复分支；问题被修复完后，再将该修复分支合并到专门用于测试该问题的测试分支中；
临时分支：被合并到发布分支（即正式发布之后）才可以被删除；建义正式发布运行一段时间之后再删除；如果不必要，也不建义永久留着，以便仓库保持整洁；
每个预发布分支都有其唯一对应的测试分支，每个测试分支都有其唯一对应的被转测分支；即：每个被转测分支都有其单独对应的测试分支，每个测试分支都有其单独对应的预发布分支；（这是为了保证对应的预发布分支、测试分支、被转测分支的代码的一致性，多个任务或多个功能之间独立、互不干扰）

注意： 本规范（分支的流转规范）中所述的合并操作可以是一般的分支合并操作，也可以是 Pull requests ，这个取决仓库的管理策略；所以，本规范也适用于那些用多个仓库管理同一个项目的 Git仓库管理策略；

分支流转规范图

高清图详见：分支流转规范图-高清、分支流转规范图-高清透明
该图的设计思路详见：Git并行工作流程规范设计记录

7. 分支合并规范

为了使分支各司其职，演进清晰简洁，分支的变更单元可用提交节点表示，我们在合并分支时需要按照一定的规范来操作，具体如下：

对于分支的流转规范（见上文 6）中的分支合并操作必须使用非快进式合并（见下文 禁止快进式合并）；
长期分支应以孤儿分支（见下文 创建空分支独立分支孤儿分支）的方式被创建；
创建临时分支时，可根据自己的喜欢选择是以孤儿分支的方式创建，还是不以孤儿分支的方式创建；
拉取（pull）分支时，应以变基的方式（加上 --rebase|-r 选项）拉取（pull）（见下文 用变基的方式pull）；

8. 提交规范

8.1. 提交操作规范

为了保持分支提交历史的清晰、独立，在提交更改时，我们应做到：

每一个提交都应该是一个完整、独立的变更单元；
撰写符合提交说明规范（见下文8.2）的提交说明信息；
对于修复错别字、添加遗漏的更改等等之类的提交应与对应的提交合并，不应为其创建单独的提交；

多个提交合并成一个的各种方法请看Git中合并多个提交的各种方法

8.2. 提交说明规范

Git 每次提交代码，都必须要写提交说明； Git 对提交说明的格式是没有限制的，你想怎么写就怎么写，如下：

杂乱的提交说明

但是，类似这种没有格式的提交说明有以下缺点：

不能很快分辨出提交的代码是增加了新功能、还是修复了bug、还只是更新了文档等等；
不能有效地过滤某一类提交，比如：只想查看修复bug类的提交；
不能根据需要过滤并导出提交信息，作为变更日志：比如，应用的升级的新功能说明、问题修复说明等等；

为了方便查看、过滤提交说明，我需要将提交说明格式化、规范化；目前，有多种提交说明的写法规范。但我推荐 Angular提交说明规范，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。

关于 Angular提交说明规范的详细文章请见：

Angular提交说明规范
Commit message 和 Change log 编写指南

下面是我对 Angular提交说明规范一个汇总描述；

8.2.1. Angular提交说明规范

Angular提交说明的格式如下

[Scope]:
<空一行>
[Body]
<空一行>

提交说明包括三个部分：Header（第一行）、Body（可选）和 Footer（可选），用空行分隔；其中 Body、Footer 都是可选的，可以省略；
任何一行都不得超过72、100个字符；这是为了避免自动换行影响美观
Header：只占第一行，包括三个字段：Type（必需）、Scope（可选）和 Subject（必需）；
- Type：必需；用于说明提交的类别，只允许使用下面7个标识：
  - feat：新功能（feature）
  - fix：修补bug
  - docs：文档（documentation）
  - style：格式（不影响代码运行的变动）
  - refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  - test：增加测试
  - chore：构建过程或辅助工具的变动
  如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
  提示： 为了醒目，也可以为每个 Type 分别指定一个 Emoji 表情，将其放在 Type 前面或后面；
- Scope：可选；用于说明提交的影响范围，比如数据层、控制层、视图层等等，视项目不同而不同。
- Subject：提交目的的简短描述；要求如下：
  - 不超过50个字符。
  - 以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes
  - 第一个字母小写
  - 结尾不加句号 .
Body：对本次提交的详细描述，
- 可以分成多行。
- 使用第一人称现在时，比如使用change而不是changed或changes。
- 应该说明代码变动的动机，以及与以前行为的对比。
Footer：Footer 部分只用于两种情况。
1. 不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
2. 关闭 Issue：如果当前提交针对某个 issue 的，那么可以在 Footer 部分用 Closes #234 关闭这个 issue ；也可以用 Closes #123, #245, #992 一次关闭多个 issue ；
特殊情况： 如果当前提交用于撤销以前的提交，则：
- Header 必须以 revert: 开头，后面跟着被撤销的提交的 Header。
- Body 部分的格式是固定的，必须写成This reverts commit .，其中的 hash 是被撤销的提交的 SHA 标识符。
  如果当前提交与被撤销的提交，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的 Reverts 小标题下面。

9. 相关技巧

规范有了，但在实施规范的过程中会遇到各种技术难题，为了完整性，我又研究并提供了实施规范过种中各种问题的解决方案，并把这些方案撰写成文 Git技巧和问题解决方案，下面仅是本文涉及到的相关技巧：

9.1. 禁止快进式合并

git在执行合并操作时（无论是通过 merge 命令，还是通过 pull 命令），比如将分支B 合并进分支A 中，如果分支A 完全包含在分支B 的历史中（如下图），

快进合并前

那么，git 默认会以快进的方式进行合并，合并后的效果如下：

快进式合并

非快进式合并的效果如下：

非快进式合并

如果想禁用快进式合并，可以给命令传递 --no-ff 选项， ff 是快进的英文 fast farward 缩写；如下：

merge命令：

git merge  --no-ff  <分支B>

pull命令：

git pull --no-ff

merge 和 pull 命令中与快进式合并相关的选项如下：

--ff : 当可以快进合并时，使用快进合并的方式进行合并。这是默认行为。
--no-ff : 即使可以快进合并，不会使用快进式合并，而是也创建一个合并提交。这是合并注释（可能有符号）标记时的默认行为。
--ff-only : 如果可以快进式合并，则会进行快进式合并；否则，取消合并操作；

9.2. 创建空分支（独立分支、孤儿分支）

我们可以通过以下命令创建新分支：

git branch <新分支名>
git checkout -b <新分支名>

这种方式创建的新分支都是基于当前的 HEAD 来创建分支的，新的分支会和当前 HEAD 拥有共同的提交历史；
例如，假设当前 HEAD 在分支A 上，如下图所示，

创建独立分支前

通过 git branch 分支B 或 git checkout -b 分支B 来创建分支B 后，分支图如下所示：

创建非独立分支

新建的分支B 和分支A 会有相同提交历史；

如果我们想创建一个没有任何历史的分支，我们可以用带 --orphan 选项的 checkout 命令，语法如下：

git checkout --orphan <新分支名> [开始点]

--orphan 选项指定创建一个孤儿分支，即：独立的分支、没有任何提交历史的分支；并且会切换到这个新的分支；
此时，你通过 branch 命令列出的分支列表里是没有这个分支的，因为该分支里没有任何提交，分支没有可被引用的提交对象；
并且，此时，新分支的暂存区中存放的是 开始点 处目录树中的所有文件，如果没有指定 开始点 参数，则默认会把当前的 HEAD 作为开始点；
如果不想要暂存区的任何东西，可以执行 git rm -rf . 命令清空暂存区；
如果想将 开始点 处的整个目录树作为新分支的第一个版本进行提交，直接执行 commit 命令 git commit -m "提交信息" 即可；

如：当前在HEAD分支A，执行如下命令：

git checkout --orphan 分支B
git commit -m "提交信息"

分支图如下所示：

创建独立分支

合并独立分支的方法请看合并不相关的分支（没有共同历史的分支）

9.3. 合并不相关的分支（没有共同历史的分支）

Git默认的合并操作只会对有共同提交历史的分支进行合并；

有共同历史的分支

不过，对没有共同提交历史的分支进行合并的情况也是存在的，比如：

合并孤儿分支；
两个仓库，但文件内容相似，甚至就是同一个项目，需要将这两个仓库中的分支进行合并

不相关的分支

若想对没有共同历史的分支进行合并，只需给 merge 或 pull 命令（pull命令也会有合并的操作）添加 --allow-unrelated-histories 选项，语法如下：
merge语法：

git merge  --allow-unrelated-histories  <分支名>

pull语法：

git pull  --allow-unrelated-histories

不相关分支的合并

9.4. 只合分支并保持历史的线性

假设有分支A 和分支B ，当前在分支A，如下图：

squash合并前

当我们进行合并分支时，通常会将指定分支的变更合并到当前分支中，并产生一个提交，该提交会有两个父提交的引用；如下图：

非squash合并

如果我们想合并其它分支的变更，但又想保持当前分支的线性，使分支的提交历史上没有分支交汇的情况，即：每一个提交对象都有一个父提交的对象，而非多个父提交对象；那该怎么操作呢？

我们可以给 merge 或 pull 命令（pull命令也会有合并的操作）添加 --squash 选项，语法如下：
merge语法：

git merge  --squash  <分支名>