Git-分阶段合併&压缩合併

两条分支成功合併，并不代表程式码是OK的，譬如，商业逻辑的错误。
通常合併之后，都还会经过测试。

分阶段合併

延续Git-fast-forward快转模式。
先将feature分支砍掉，再重新建立。
并且新增2个档案。

feature分支领先master分支两个版本。

在master分支合併feature分支，预设会使用fast-forward。
上一篇也提过，fast-forward不会有commit。若使用分支合併，就会产生合併commit。
那能否在使用分支合併当中，先不要commit，等我们确认程式码无误，再进行commit呢？

答案是可以的。
使用--no-commit，这样一来，就不会先commit，而是让我们确认完毕，再自行手动commit。

讯息表示：合併正常进行，但在我们要求commit之前停止了。
换句话说，我们要自行commit，这个合併才会完成。
这时的分支状态(master|MERGING)，显示正在合併中。

即使合併未完成，资料夹目录却已经变更了。

查看git status。

讯息表示：没有冲突，但仍然在合併中的状态。
(use "git commit" to conclude merge)，讯息提示，使用git commit来结束这次合併。

我们在这段期间，可以对资料做任何异动，假设再增加一个档案。

查看git status。

新增成功。

执行git commit完成合併。
我们可以自行增加commit讯息：add 3.txt。

OK，成功合併。

线图。

以上就是，将合併拆成两阶段来执行的过程。

压缩合併

回复刚刚的合併。指令 git reset --hard ORIG_HEAD
在master分支新增档案，执行commit。

这时，master分支与feature分支，都有各自的commit，所以合併不会使用fast-forward模式。
使用fast-forward模式，有个明确的规範，即将合併的版本，必须是自己的之后版本。

压缩合併指令：--squash

讯息跟刚刚差不多。
Squash commit -- not updating HEAD：表示因为使用压缩合併，git不会更新HEAD，这部分我们要自行更新。

查看git status

合併完成，但还没有commit。

资料夹目录却已经变更

所以，压缩合併到底是什么？
压缩合併的功能，是将feature分支所有的commit(2个)全部压缩至master分支的下一个commit。

执行git commit，讯息会说明，这次的合併，会压缩以下的commit，正是feature分支的commit。

压缩合併完成后，讯息会说明已完成下面commit的压缩。

查看线图，会发现，feature分支像断掉一样，并没有延伸至master分支最新的commit。

这是因为刚刚说过的，压缩合併的结果，会在master分支再建立一个新的commit，包含所有的feature分支commit。
也可以这样说，git会压缩feature分支的所有commit，并加入master分支的下一个commit。

git log讯息很清楚的说明，这次的commit包含了哪些压缩的commit。

使用压缩合併的情境

假设我们只是在分支做个小测试，并不需要特地保留合併分支的线图。
这时就可以使用压缩合併。

删除分支

删除后的线图

会发现，feature分支整个消失了，但它的commit结果还是会在master分支之中。

使用限制

最后一点要说的是，--no-ff与--squash指令，是不允许一起使用的。

因为，--no-ff会强迫有分岔的线图；但--squash不会产生分岔的线图，
他们是冲突的，所以这样的指令当然会失败。

本文为观看网路教学的学习笔记。