详解git中的merge: 合并commits

pull的内部操作其实是把远程仓库取到本地后（使用的是fetch），再用一次merge来把远端仓库的新commits合并到本地。本文就说一下，merge到底是什么。

含义和用法

merge的意思是「合并」，它做的事也是合并：指定一个commit，把它合并到当前的commit来。具体来讲，merge做的事是：

从目标 commit 和当前 commit （即 HEAD 所指向的 commit ）分叉的位置起，把目标 commit 的路径上的所有 commit 的内容一并应用到当前 commit ，然后自动生成一个新的 commit 。

例如下面这个图中：

HEAD指向了master，所以如果这时执行：

git merge branch1

Git 会把5和6这两个commit的内容一并应用到4上，然后生成一个新的提交，并跳转到提交信息填写的界面：

merge操作会帮你自动地填写简要的提交信息。在提交信息修改完成后（或者你打算不修改默认的提交信息），就可以退出这个界面，然后这次merge就算完成了。

适用场景

merge有什么用？最常用的场景有两处：

1. 合并分支当一个branch的开发已经完成，需要把内容合并回去时，用merge来进行合并。那branch又应该怎么用呢？下节就说。
2. pull的内部操作之前说过，pull的实际操作其实是把远端仓库的内容用fetch取下来之后，用merge来合并。

特殊情况 1：冲突

merge在做合并的时候，是有一定的自动合并能力的：如果一个分支改了 A 文件，另一个分支改了 B 文件，那么合并后就是既改 A 也改 B，这个动作会自动完成；如果两个分支都改了同一个文件，但一个改的是第 1 行，另一个改的是第 2 行，那么合并后就是第 1 行和第 2 行都改，也是自动完成。

image

但，如果两个分支修改了同一部分内容，merge的自动算法就搞不定了。这种情况 Git 称之为：冲突（Conflict）。

直白点说就是，你的两个分支改了相同的内容，Git 不知道应该以哪个为准。如果在merge的时候发生了这种情况，Git 就会把问题交给你来决定。具体地，它会告诉你merge失败，以及失败的原因：

git merge feature1

提示信息说，在shopping list.txt中出现了 "merge conflict"，自动合并失败，要求 "fix conflicts and then commit the result"（把冲突解决掉后提交）。那么你现在需要做两件事：

1. 解决掉冲突
2. 手动commit一下

1. 解决冲突

解决掉冲突的方式有多个，我现在说最直接的一个。你现在再打开shopping list.txt看一下，会发现它的内容变了：

可以看到，Git 虽然没有帮你完成自动merge，但它对文件还是做了一些工作：它把两个分支冲突的内容放在了一起，并用符号标记出了它们的边界以及它们的出处。上面图中表示，HEAD中的内容是移动硬盘（已买），而feature1中的内容则是移动硬盘（不买了）。这两个改动 Git 不知道应该怎样合并，于是把它们放在一起，由你来决定。假设你决定保留HEAD的修改，那么只要删除掉feature1的修改，再把 Git 添加的那三行<<<===>>>辅助文字也删掉，保存文件退出，所谓的「解决掉冲突」就完成了。

你也可以选择使用更方便的merge工具来解决冲突，这个你可以自己搜索一下。

2. 手动提交

解决完冲突以后，就可以进行第二步------commit了。

git add shopping list.txt # 嗯是的，这里 commit 前也需要先add一下
git commit

可以看到，被冲突中断的merge，在手动commit的时候依然会自动填写提交信息。这是因为在发生冲突后，Git 仓库处于一个「merge 冲突待解决」的中间状态，在这种状态下commit，Git 就会自动地帮你添加「这是一个 merge commit」的提交信息。

放弃解决冲突，取消 merge？

同理，由于现在 Git 仓库处于冲突待解决的中间状态，所以如果你最终决定放弃这次merge，也需要执行一次merge --abort来手动取消它：

git merge --abort

输入这行代码，你的 Git 仓库就会回到merge前的状态。

特殊情况 2：HEAD 领先于目标 commit

如果merge时的目标commit和HEAD处的commit并不存在分叉，而是HEAD领先于目标commit：

那么merge就没必要再创建一个新的commit来进行合并操作，因为并没有什么需要合并的。在这种情况下， Git 什么也不会做，merge是一个空操作。

特殊情况 3：HEAD 落后于 目标 commit------fast-forward

而另一种情况：如果HEAD和目标commit依然是不存在分叉，但HEAD不是领先于目标commit，而是落后于目标commit：

那么 Git 会直接把HEAD（以及它所指向的branch，如果有的话）移动到目标commit：

git merge feature1

这种操作有一个专有称谓，叫做 "fast-forward"（快速前移）。

一般情况下，创建新的branch都是会和原branch（例如上图中的master）并行开发的，不然没必要开branch，直接在原branch上开发就好。但事实上，上图中的情形其实很常见，因为这其实是pull操作的一种经典情形：本地的master没有新提交，而远端仓库中有同事提交了新内容到master：

那么这时如果在本地执行一次pull操作，就会由于HEAD落后于目标commit（也就是远端的master）而造成 "fast-forward"：

git pull

简单解释一下上图中的origin/master和origin/HEAD是什么鬼：它们是对远端仓库的master和HEAD的本地镜像，在git pull的「两步走」中的第一步------git fetch下载远端仓库内容时，这两个镜像引用得到了更新，也就是上面这个动图中的第一步：origin/master和origin/HEAD移动到了最新的commit。

为什么前面的图里面从来都没有这两个「镜像引用」？因为我没有画呀！其实它们是一直存在的。

而git pull的第二步操作merge的目标commit，是远端仓库的HEAD，也就是origin/HEAD，所以git pull的第二步的完整内容是：

git merge origin/HEAD

因此HEAD就会带着master一起，也指向图中绿色的最新commit了。

小结

本文对merge进行了介绍，内容大概有这么几点：

1. merge的含义：从两个commit「分叉」的位置起，把目标commit的内容应用到当前commit（HEAD所指向的commit），并生成一个新的commit；

2. merge的适用场景：

   1. 单独开发的branch用完了以后，合并回原先的branch；
   2. 1. git pull的内部自动操作。

3. merge的三种特殊情况：

   1. 冲突

      1. 原因：当前分支和目标分支修改了同一部分内容，Git 无法确定应该怎样合并；
      2. 应对方法：解决冲突后手动commit。

   2. HEAD领先于目标commit：Git 什么也不做，空操作；

   3. HEAD落后于目标commit：fast-forward。