5.0 KiB
| sidebar_label | sidebar_position |
|---|---|
| 合并模式简介 | 4 |
合并模式简介
在审阅人审查完开发者提交的代码变更后，便可以决定是否将这些提交合并进主分支master中。
然而，对于不同分支间的提交合并，存在多种合并模式，下图为GitLink中支持的合并模式，包括合并请求、变基并合并、变基合并 --no-ff以及压缩提交并合并四种。
- 合并请求
合并请求是最常用的合并模式，以下图为例，开发者在主分支master的提交3处拉取了开发分支dev，然后分别提交了A、B、C，然后在master分支上进行合并。
快进合并前：
快进合并后：
注意：可以看到，合并的过程就是直接把master指针移动到了dev指针处，这种合并被称为快进（fast-forward），之所以出现这种情形是因为在提交3之后，master分支上没有新的提交，所以通过直接快进master指针就可以完成合并；但如果在master分支上也有新的提交，就需要进行实质性的合并了，如下面两幅图所示：
在合并前，dev分支上提交A之后、提交B之前，master分支上提交了4，这时合并dev分支就不能简单地快进移动，而是要比较两个分支上更改的内容，然后进行合并；
非快进合并前：
合并之后，提交A、B、C都会按时间线加入master的提交记录中，并且会生成一个新的提交D，用于记录合并这件事情；此外，如果合并过程中发生了冲突，即两个分支对同一个文件进行了修改，则需要手动处理冲突；这种合并方式就是非快进（no fast-forward），这也是合并请求模式下的默认方式！
非快进合并后：
为了方便理解，可以以线性方式查看合并后的master分支上的提交记录
总结：在合并请求模式下，默认采用非快进合并开发分支到master分支上，而非快进方式会生成一个特殊的提交用于记录此次合并事件！
- 变基并合并
从合并请求后master分支上的提交记录可以看出，两个分支的提交记录可能会交叉在一起，这可能会给后续开发带来困扰，而变基并合并可以解决这个问题。
变基并合并包括两个操作：变基、合并。首先是变基，以下图为例，dev分支是从提交3处拉取出来的，所以提交3就是dev的基，而变基操作就是改变dev的基，使其变为master分支上最新的一次提交。当然，变基过程中可能会出现冲突，则需要手动处理。
变基前：
变基后、合并前：
dev分支变基之后，master分支就没有“更新”的提交了，所以此时进行合并，就得到了如下的结果
合并后：
总结：在变基并合并模式下，开发分支dev可以先进行变基操作，使其上的提交看起来都是在master分支最新的提交基础上进行的，然后再通过快进方式合并回master分支，从而起到整理提交记录的作用！
- 变基合并 --no-ff
因为变基并合并进行合并操作时，默认采用快进方式，这样在master分支上就没有一个特殊的提交用于记录这次合并事件，所以可以使用--no-ff（no fast-forward）选项申明采用非快进方式进行合并。
--no-ff合并前：
--no-ff合并后：
总结：通过--no-ff选项，可以显式声明在合并时采用非快进方式，这样就可以在master分支中添加一个记录合并事件的提交！
- 压缩提交并合并
在dev或者feature这样的开发分支中，开发者为了完成某个需求会进行多次提交，然而这些琐碎的提交信息在合并回master分支后，会使master上的提交记录臃肿混乱，所以需要在合并前，对这些提交进行压缩。如图所示，压缩操作是在master分支上进行的，本质是将dev分支上进行的变更施加到master分支维护的文件上，然后将这些修改用新的提交5保存，最后提交。
压缩前：
压缩后、提交前：
提交后：
总结：在合并前，先对开发分支上的琐碎提交进行压缩，可以使master分支上的提交信息更简洁，但是要注意，这种合并模式本质上是master分支一次性保存dev上的变更，并创建新的提交记录这些变更，所以提交者发生了变化！