你知道git rebase 和 git merge的区别吗？

它们是什么

在使用git进行版本管理的项目中，当完成一个功能的开发并将其合并到master分支时，会有两种方式：

• git merge
• git rebase

git rebase 与 git merge都有相同的作用，都是将一个分支的提交合并到另一分支上，但是在原理上却不相同。

用法上两者也十分的简单：

git merge

将当前分支合并到指定分支，命令用法如下：

git merge xxx

git rebase

将当前分支移植到指定分支或指定commit之上，用法如下：

git rebase -i <commit>

常见的参数有--continue，用于解决冲突之后，继续执行rebase

git rebase --continue

这两个的执行

git merge

通过git merge将当前分支与xxx分支合并，产生的新的commit对象有两个父节点，如果"指定分支"本身是当前分支的一个直接子节点，则会产生快照合并。

举个例子，bugfix分支是从master分支分叉出来的，如下所示：

合并bugfix分支到master分支时，如果master分支的状态没有被更改过，即 bugfix分支的历史记录包含master分支所有的历史记录，所以通过把master分支的位置移动到bugfix的最新分支上，就完成合并。

如果master分支的历史记录在创建bugfix分支后又有新的提交，如下情况：

这时候使用git merge的时候，会生成一个新的提交 ，并且master分支的HEAD会移动到新的分支上，如下：

从上面可以看到，会把两个分支的最新快照以及二者最近的共同祖先进行三方合并，合并的结果是生成一个新的快照。

git rebase

同样，master分支的历史记录在创建bugfix分支后又有新的提交，如下情况：

通过git rebase，会变成如下情况：

在移交过程中，如果发生冲突，需要修改各自的冲突，如下：

rebase之后，master的HEAD位置不变。因此，要合并master分支和bugfix分支：

从上面可以看到，rebase会找到不同的分支的最近共同祖先，如上图的B，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件 （老的提交X和Y也没有被销毁，只是简单地不能再被访问或者使用） ，然后将当前分支指向目标最新位置D, 然后将之前另存为临时文件的修改依序应用。

区别

从上面可以看到，merge和rebasea都是合并历史记录，但是各自特性不同：

1. 工作原理：

   • git merge：将一个分支的更改合并到另一个分支。它会创建一个新的提交，该提交将两个分支的更改合并在一起，并且保留了每个分支上的历史记录。
   • git rebase：将当前分支的提交"移动"到目标分支的顶部，而不是创建一个新的合并提交。它会将当前分支的更改应用到目标分支的提交上，然后将当前分支移动到目标分支的最新提交之后。

2. 提交历史：

   • git merge：保留了每个分支的提交历史，并创建了一个新的合并提交，其中包含了两个分支的更改。
   • git rebase：将当前分支的提交"重播"在目标分支的提交之上，因此它会产生一个更线性的提交历史，看起来更加清晰。这种方法有助于保持项目历史的整洁性，但可能会导致变基后的提交 ID 发生变化，这可能会影响到已共享的提交。

3. 合并冲突处理：

   • git merge：在合并过程中，如果存在冲突，Git 会创建一个合并提交，并提示用户手动解决冲突。解决完冲突后，再提交合并结果。
   • git rebase：在重新应用每个提交的过程中，如果存在冲突，Git 会在每个冲突点停止，让用户解决冲突。然后用户可以使用 git rebase --continue 命令继续重新应用提交，直到全部提交都被应用完毕。

4. 使用场景：

   • git merge：适用于合并相对较稳定的分支，如主分支或者长期存在的开发分支。它将保留每个分支的完整历史记录，并创建一个新的合并提交，记录合并时的状态。
   • git rebase：通常用于将开发分支与目标分支同步，以便于保持一个清晰、线性的提交历史。这有助于避免分支合并后产生大量的合并提交，使得提交历史更易于理解和管理。