聊聊Git 合并和变基

一、 Git Merge 合并策略

1.1 Fast-Forward Merge（快进式合并）

//在分支1下操作，会将分支1合并到分支2中
git merge <分支2>

最简单的合并算法，它是在一条不分叉的两个分支之间进行合并。快进式合并是默认的合并行为，并没有产生新的commit。如下图所示，虚线部分是合并前，在经过如下命令后：

//当前在Main分支下操作
git merge Dev 

Git 将 Main 和 HEAD 指针移动到 Dev 所在的提交对象上，此时合并完成，不涉及到内容的变更和比较，所以这种合并方式效率很高。从上面的图可以发现，这种合并策略要求合并的两个分支上的提交，必须是一条链上的前后关系。
可以通过git merge --no-off参数来进行关闭快进式合并，关闭后会强制使用Three Way Merge（三路合并），下面来具体讲讲三路合并

1.2 Three Way Merge 三路合并

当两个分支的提交对象不在一条提交链上时，Git 会默认执行三路合并的方式进行合并。
首先 Git 会通过算法寻找两个分支的最近公共祖先节点，再将找到的公共祖先节点作为base节点，并使用三路合并的策略来进行合并，也就是我们常见的合并方式（三路指的是两个需要合并的分支的提交对象（比如下图中的提交对象 1,2），最近共同祖先（提交对象 0）三个对象）：

可以通过传递不同参数来使用不同的合并策略：
git merge [ -s ] [-X ] ...

• 参数 -s 用于设定合并策略

• 参数 -X 用于为所选的合并策略提供附加的参数

  1.3.2 Resolve策略

  Resolve 策略是默认的三路合并策略，既可以使用 git merge <分支>又可以使用 git merge -s resolve <分支>来执行合并，该合并策略只能用于合并两个分支，也就是当前分支和另外的一个分支，使用三路合并策略。这种合并策略被认为是最安全、最快的合并分支策略。
  比如在 Main 分支下执行以下命令：

  //当前在Main分支下操作
  git merge Dev

  
  Git 会创建一个新的提交对象（如上图中的提交对象 3），然后该提交对象将合并提交对象 1 和提交对象 2 的内容，形成提交对象 3。但是一旦遇到两个分支对象有多个共同祖先时，此时 Resolve 策略就无法实现合并了，这个时候就需要用 Recursive策略。

  1.3.1 Recursive 策略

  如下图所示，在对两个分支上的提交A和B进行合并时，我们发现了它们有两个共同祖先，分别是：ancestor0 和 ancestor1。这就是 Criss-Cross 现象：
  
  我们在此处复现一下这个现象：

  //1.初始化一个recursiveMerge仓库
  $ git init recursiveMerge
  
  //2.创建一个master-commit1.txt文件并提交
  $ git commit -m "master-commit1"
  [master (root-commit) 85cba5f] master-commit1
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 master-commit1.txt
  
  //3.新建一个分支dev，并切换到dev。在dev分支创建一个dev-commit1.txt文件并提交
  $ git checkout -b dev
  Switched to a new branch 'dev'
  $ git commit -m "dev-commit1"
  [dev 9763dcc] dev-commit1
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 dev-commit1.txt
  
  //4.切换到master分支，创建一个master-commit2.txt文件并提交
  $ git checkout master
  Switched to branch 'master'
  $ git commit -m "master-commit2"
  [master 5c23645] master-commit2
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 master-commit2.txt
  
   //5.新建一个分支feature, 切换到feature,合并dev和feature
   $ git merge dev
  hint: Waiting for your editor to close the file... unix2dos: converting file D:/recursiveMerge/.git/MERGE_MSG to DOS format...
  libpng warning: iCCP: known incorrect sRGB profile
  libpng warning: iCCP: known incorrect sRGB profile
  dos2unix: converting file D:/recursiveMerge/.git/MERGE_MSG to Unix format...
  Merge made by the 'ort' strategy.
   dev-commit1.txt | 0
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 dev-commit1.txt
  
  //6.切换到master，合并dev和master
  $ git merge dev
  hint: Waiting for your editor to close the file... unix2dos: converting file D:/recursiveMerge/.git/MERGE_MSG to DOS format...
  libpng warning: iCCP: known incorrect sRGB profile
  libpng warning: iCCP: known incorrect sRGB profile
  dos2unix: converting file D:/recursiveMerge/.git/MERGE_MSG to Unix format...
  Merge made by the 'ort' strategy.
   dev-commit1.txt | 0
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 dev-commit1.txt
  

  我们在 Git GUI 中查看此时的分支图像：
  
  那么Recursive 策略对于这种情况是怎么做的呢？
  如果Git在寻找共同祖先时，在参与合并的两个分支上找到了不只一个满足条件的共同祖先，它会先对共同祖先进行合并，建立临时快照。然后，把临时产生的“虚拟祖先”作为合并依据，再对分支进行合并。对于上图而言，会将ancestor 0 和 ancestor 1 先合并成一个虚拟祖先 ancestor 2，最后再将它与A和B提交一起进行三路合并：
  
  在处理合并时，有可能会出现不同分支在相同文件上的冲突，因此可以使用下列选项来在发生冲突时起作用，常见的有：

  Ours选项

  在遇到冲突时，选择当前分支版本，而忽略其他分支版本。如果他人的改动和本地改动不冲突，会将他人的改动合并进来：

  # 在冲突合并中，选择当前分支内容，自动丢弃其他分支内容
  git merge -s recursive -Xours

  Theirs选项

  和 Ours选项相反，遇到冲突时，选择他人的版本，丢弃当前分支版本

  # 选择其他分支内容，自动丢弃当前分支内容
  git merge -s recursive -Xtheis

  此外还有 subtree[=]，renormalize，no-renormalize等等选项，具体可以看官方文档Git - merge-strategies Documentation

  1.3 Octopus Merge 多路合并

  git merge -s octopus <分支1> <分支2> ... <分支N>

  此合并策略可以合并两个以上的分支，但是拒绝执行需要手动解决的复杂合并，它的主要用途是将多个分支合并到一起，该策略是对三个及三个以上的分支合并时的默认合并策略。
  
  来做一个实验，此时我的 Git 仓库中有三个分支 feature1，feature2，feature3，执行 octopus 合并：

  $ git merge -s octopus feature1 feature2 feature3
  Trying simple merge with feature1
  Trying simple merge with feature2
  Trying simple merge with feature3
  Merge made by the 'octopus' strategy.
   feature1-1.txt | 0
   feature3-2.txt | 0
   four.txt       | 0
   second.txt     | 0
   third-2.txt    | 0
   third.txt      | 0
   6 files changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 feature1-1.txt
   create mode 100644 feature3-2.txt
   create mode 100644 four.txt
   create mode 100644 second.txt
   create mode 100644 third-2.txt
   create mode 100644 third.txt

  

  1.3.3 subtree策略

  这是一个经过调整的 recursive策略，当合并树 A 和树 B 时，如果树 B 和树 A 的一个子树相同，B 树首先进行调整以匹配 A 的树结构，以免两棵树在同一级别进行合并。同时也针对两棵树的共同祖先调整。

  git merge -s subtree <树A> <树B>

  该部分会单独再出一篇，来姐姐子树合并和子模块合并

  1.3.4 ours 策略

  这种策略可以合并任意数量的分支，但是合并的结果总是使用当前分支的内容，丢弃其他分支的内容。
  这种模式和上面的 recursive策略中的 ours选项不同，ours 选项是在某个分支下，忽略其他人的版本，ours策略是忽略其他的分支。

  二、 Git Rebase 变基

  rebase是指在另一个基端之上重新应用提交。很多时候我们在两个分支上用rebase。但是**rebase**命令的作用对象不仅仅限于分支。任何的提交引用，都可以被视作有效的**rebase**基底对象。包括一个提交ID、分支名称、标签名称或者**HEAD~1**这样的相对引用。

2.1 标准模式

git rebase默认是标准模式，一般用于多个分支之间：在一个分支中集成另外分支的最新修改。

#当前在Feature分支下操作,会得到如下的变基状态
git checkout Feature
git rebase Main

#当前在branch1分支下操作，会得到如下的变基状态
git checkout Branch1
#将Main分支中没有Branch1分支的提交，拷贝到Branch2分支中
git rebase Main --onto Branch2

当执行git rebase命令后，整个变基过程都会自动进行，如果在该命令后加上-i参数后，就会进入到交互模式：

2.2 交互模式

git rebase -i或者git rebase -interactive开始后执行一个交互式rebase 会话。一般用于当前分支的历史提交进行编辑操作。

# 针对该commit 后的提交进行交互式操作
git rebase -i [commit ID]

运行命令后，会跳出交互界面，比如在git bash中输入如下命令：git rebase -i ecd259f
页面会出现下面的界面：

上图中的两条记录是提交列表，指的是 ID 为ecd259f...的 commit 之前的提交。我们可以对这两个提交进行相关的操作，在上面的页面中也提供了几个命令：

• pick：保留该commit，和drop相对，也就是什么也不做（在IDEA中不选择，直接rebase，也会得到如下结果）
• reword：修改该提交的commit message，如果该commit之后也有提交，那么之后的提交信息也会被改变
• edit： 选择一个提交并修改该提交的内容
• squash：合并该提交与上一个提交，也可以合并多个，两两合并，间隔合并
• fixup：与squash类似，但是会抛弃当前的commit message
• exec: 执行shell命令，运行一条自定义命令

可以在提交列表前面进行参数修改，比如将 pick改成 squash就是将两个提交合并到 ID 为 ecd259f...的提交对象中

squash a5eb754 first commit --init
squash 2df01ad ignoreList

三、总结

Git merge 和 Git rebase 的区别与联系

在日常对冲突的处理中，很明显的区别在于 rebase 的处理方式能让提交链更加清晰，而使用 merge 方式会显得提交链复杂交错。
下面我们具体来看看两者的区别与联系

区别

1. 合并方式：git merge 创建一个新的合并提交，将两个分支的更改合并到一起，而 git rebase 将一系列提交从一个分支转移到另一个分支，并重新组织这些提交：
2. 提交历史：git merge 保留每个分支的独立提交历史，形成一个合并的提交历史树，而git rebase修改提交历史的结构，使提交历史更线性：

3. 冲突处理：在合并过程中，如果存在冲突，git merge 和 git rebase 都需要手动解决冲突。但是，解决冲突的方式略有不同。git merge 在合并提交中保留冲突的解决方案，而 git rebase 在每个冲突点停下来，必须在解决冲突后才能继续进行rebase操作。

4. 提交ID：由于 git rebase 重新应用提交，所以重新组织后的提交具有新的提交ID，而 git merge 创建的合并提交保留了原始提交的ID。比如上图中，git rebase 命令执行后，对应的 master 分支的三个 commit 对象的提交 ID 都要被修改。

   联系

5. 合并操作：无论是 git merge 还是 git rebase，它们都是用于将一个分支的更改合并到另一个分支上。两者都是在对分支进行合并，是来解决冲突的。
6. 版本同步：无论是 git merge 还是 git rebase，它们都可以用于将分支与上游分支同步，以确保分支包含上游的最新更改。

7. 解决冲突：无论是 git merge 还是 git rebase，在合并过程中都可能存在冲突，需要手动解决冲突。

   参考资料

   https://www.geeksforgeeks.org/merge-strategies-in-git/
   https://morningspace.github.io/tech/git-merge-stories-2/
   https://git-scm.com/docs/merge-strategies/