本文一共3165字，将通俗的解释git中两种合并策略——merge和rebase的不同、运用方式和使用的场景，并辅以我在工作中的运用来介绍；

什么是git merge？

git merge是我们在git操作中频繁会用到的一个命令，它主要实现的功能便是为我们进行分支代码的合并，也就是将两个或两个以上的开发历史合并在一起的操作。

它有以下两种用途：

1. 更新代码时，整合另一个代码仓库中的变化，也就是git pull命令中，我们使用git pull命令时，实际上相当于git fetch+git merge，进行了远程仓库代码的拉取，以及整合另一代码仓库中的变化
2. 用于从一个分支到另一个分支的合并，我们一般会通过该命令进行从指定的commit(s)合并到当前分支的操作，要注意的是这里的指定commit(s)是指从这些历史commit节点开始，一直到当前分开的时候。

git merge有个重要的特点，便是在合并过程中，它会创建一个新的commit节点，来作为我们的合并结果节点，如下图

a. 假设master目前的历史提交情况如下，head处于commit-D的位置。

b. 我们从D的位置，checkout出一个新分支feature，并增加了两次提交E和F。

c. 然后我们想将feature分支合并到master上，此时我们只需要在master分支上执行

git merge feature

此时将在master上将合并结果生成一个新的commit节点G，最终推送远程分支。

可见merge命令的强大和便利，通过分支来完成需求代码的编写，再通过合并的方式，保证了主分支的整洁性。

什么是git rebase？

说完了git merge，我们来说一说git rebase。

我们可以把git rebase理解成是“重新设置基线”，将你的当前分支重新设置开始点。我们便能知道你当前分支与你需要比较的分支之间的差异。

也就是基于一个分支来设置你当前的分支的基线，这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面，这样你的当前分支就是最新的跟踪分支。

它有以下几点用途：

1. 合并提交记录，比如说对于我们拉取出来的开发分支，可能会在开发过程中多次提交测试，会产生很多不规范的、不必要的提交，这类提交将会造成我们的分支污染，当出现问题需要回退时，将增加难度。
2. 合并分支，乍一看好像与merge命令拥有同样的功能，是的，它们都能合并，不过彼此的合并原理却大大不同，git merge是将合并结果产生新节点，不影响历史的提交，而git rebase是基于变基的操作，它会将分支的开始点基于rebase的分支重新设置，并将rebase的分支重新提交，直接贴到该分支开始点之后，再之后才是该分支自己的提交。

多说无益，我们根据这两点来描述下场景，加深大家的理解：

合并提交记录

假设此时分支上有三次提交，分别是first commit，second commit，third commit，我希望将前两次进行合并，最终得到两次提交的结果。

a. 我们使用“git rebase -i HEAD~3”命令查看最近三次提交，并打开一个编辑器，其中第一列为“操作指令”，第二列和第三列为我们的提交信息：

b. 操作指令包括：

pick：保留该commit；
reword：保留该commit但是修改commit信息；
edit：保留该commit但是要修改commit内容；
squash：将该commit和前一个commit合并；
fixup：将该commit和前一个commit合并，并不保留该commit的commit信息；
exec：执行shell命令；
drop：删除该commit。

在本次操作中，我们将使用squash命令，将第二个合并到第一个里面去，修改后保存退出，如下：

c. 保存退出，进入编辑器，对合并后的commit信息进行编辑，我们将“1&2 commit.”编辑到this is a combination of 2 commits的下面。并保存退出。

d. 最后我们来看下结果，通过git log看日志 或者 git rebase -i，可见第二次提交已经不见了，第一次提交的提交信息变成了我们刚刚修改的“1&2 commit.”。便完成了提交记录的合并。

合并分支

假设我们现在有个需求开发，所以我们就从主分支master上拉出了一个开发分支dev，在该分支上迭代代码，但此时其他同事也在同时进行开发，也就是如下情况：

若dev2分支提前完成，将代码合并到了master分支上了，此时master分支就变成如下：

那么为了提交不冲突，此时我们会使用merge命令，将修改后的master合并到dev分支上，结果便会导致dev分支会出现一些merge的信息，污染了dev分支的commits，那么此时我们就可以使用rebase命令，来将master的变化合并到dev上，该操作会将dev分支的开始节点进行变基，变成master当前的状态，再增加我们的新修改

也就是说，当我们在dev分支上使用git rebase master后，git会把dev分支里面的每个commit取消掉，然后把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；然后，把 dev 分支更新到最新的 master 分支；最后，把上面保存的 patch 文件应用到 dev 分支上；

结果便是，原先dev分支是从C开始的，通过变基后，变成了从H开始，就相当于此时刚从master拉取的一个新分支，这么一看，是不是dev的commit-log就变成很整洁，没有受到污染呢。

两者的区别

通过上述两者的描述，我们就能总结出这两个命令的区别啦：

rebase：会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。

就像刚刚上面的例子: 如果你从 master 拉了个dev分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。

merge：会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交。

两者的使用场景

merge命令一般用于将开发分支、热修复分支等合并到主分支上，因为该命令不会修改分支的历史信息，只会增加新节点，非常适合主分支这种稳定性且需要用于版本控制的分支上。

rebase命令一般用于将基分支的新提交记录，合并到正在进行开发任务或修复任务的分支上，因为该命令能保证开发分支的历史与基分支的历史保持一致，从而减少污染性。

但要注意，rebase命令最好不要用于一个公共的分支，假设你们公司的开发分支是一个公用的分支，此时多人在这个分支上开发，由于rebase的修改历史的特点，可能会出现丢失修改的问题，对于这种运用，建议团队之间进行沟通后决定使用merge或rebase来保证该公用开发分支的可用和完整。

我在工作中的运用

在工作中，我们会拥有自己的开发分支，在完成需求需要进行版本迭代的时候，会将开发分支的提交合并到master上，一般我的操作如下：

a. 通过git stash，将我自己开发分支的代码保存到暂存区中，恢复本地仓库到修改前的状态；

b. checkout master进入主分支，git pull拉取master的最新commits；

c. checkout mydev进入开发分支，通过git rebase master将master最新的提交，合并到自己的开发分支上， 保证该分支的历史提交与master相同；

d. git stash pop将自己的修改取出；git commit、git push提交到远程开发分支上；

e. 发起merge请求，合并到master分支；