Git merge和rebase分支合并命令的区别

欢迎关注富途web开发团队，缺人从众

上周花了时间把futu web博客分类,文章，入口搞了一下，主要为了解决SEO问题。接下来SEO好很差就看效果了。

futu web 博客地址

今天分享的文章呢。小编以为你们看图就行。正文讲的是Git分支合并命令merge和rebase的区别。

那么在正文开始前，小编仍是先送一些彩蛋吧。对于你们去理解Git命令挺有用的。

文件状态转换：

文件存储：

上面这两张图会对你们理解Git命令有很大的帮助。

正文

在使用 git 进行版本管理的项目中，当完成一个特性的开发并将其合并到 master 分支时，咱们有两种方式：git merge 和 git rebase。一般，咱们对 git merge 使用的较多，而对于 git rebase 使用的较少，其实 git rebase 也是极其强大的一种方法。下面咱们就来说一讲 git merge 和 git rebase 的差异和在实际中的使用。

准备工做

为了更好地观察执行 git merge 和 git rebase 以后发生的现象，咱们首先来作一些准备工做，即建立一个项目仓库，而后在其中构建两条分支，再增长几回提交。

具体以下：

1. 建立一个目录 gitTest
2. 在目录 myTest 中新建一个文件 readme.md，随便添加一个标题，和第一个列表项 add master1 并提交到本地仓库
3. 在当前分支的基础上新建一条分支，名为 feature，将列表项 add master1 修改成 add feature1 并提交到本地仓库
4. 随后切换到分枝 master 上添加一个新的列表项 add master2 并提交到本地仓库
5. 随后切换到分枝 feature 上添加一个新的列表项 add feature2 并提交到本地仓库
6. 重复上面的步骤 4 和 5，直至在 master 和 feature 上各添加了 4 条列表项

此时你的仓库分支提交的记录看起来应该是这样的：

初始 master 分支内容应该是这样的：

初始 feature 分支内容应该是这样的：

git merge

从目录 gitTest 拷贝出一份来，命名为 gitMerge 来进行咱们的合并操做。

git merge 的使用方法很简单，假如你想将分支 feature 合并到分支 master，那么只需执行以下两步便可：

• 将分支切换到 master 上去：git checkout master
• 将分支 feature 合并到当前分支（即 master 分支）上：git merge feature

如上图所示，git merge 有以下特色：

• 只处理一次冲突
• 引入了一次合并的历史记录，合并后的全部 commit 会按照提交时间从旧到新排列
• 全部的过程信息更多，可能会提升以后查找问题的难度

为何讲 git merge 提交的信息过多可能会影响查找问题的难度呢？由于在一个大型项目中，单纯依靠 git merge 方法进行合并，会保存全部的提交过程的信息：引出分支，合并分支，在分支上再引出新的分支等等，相似这样的操做一多，提交历史信息就会显得杂乱，这时若是有问题须要查找就会比较困难了。

使用 git merge 以后的分支提交记录以下：

git rebase

git rebase 的合并操做

与 git merge 一致，git rebase 的目的也是将一个分支的更改并入到另一个分支中去。

如上图所示，他的主要特色以下：

• 改变当前分支从 master 上拉出分支的位置
• 没有多余的合并历史的记录，且合并后的 commit 顺序不必定按照 commit 的提交时间排列
• 可能会屡次解决同一个地方的冲突（有 squash 来解决）
• 更清爽一些，master 分支上每一个 commit 点都是相对独立完整的功能单元

那么咱们如今来具体操做一下，看看 git rebase 是如何作的。

首先，和 git merge 不一样的是，你须要在 feature 分支上进行 git rebase master 的操做，意味着让当前分支 feature 相对于 分支 master 进行变基：

能够看出，咱们遇到了冲突，进行对比的双方分别是 master 分支的最新内容和 feature 分支的第一次提交的内容，上图下方红框内容告诉咱们，在咱们解决了冲突以后，须要执行 git rebase --continue 来继续变基的操做。

在解决冲突以后执行 git rebase --continue 时遇到了提示，看来咱们首先须要把咱们的修改存到暂存区，随后再执行 git rebase --continue。执行以后又遇到了冲突，此次是与 feature 分支的第二次提交进行对比出现的冲突，意味着咱们须要屡次解决同一个地方的冲突。

继续重复先解决冲突，再 git rebase --continue 的步骤，直到遇到：

意味着完成了 feature 最后一次提交的变基操做，至此整个变基就完成了。

再来看看执行 git rebase 以后的 feature 分支：

彻底符合上面所说的执行 git rebase 的特色，咱们引出 feature 分支的位置变了，没有多余的提交历史，且提交的时序也改变了，另外回忆一下，在咱们执行变基的过程当中也屡次解决了同一个地方的冲突。

这个时候咱们再切换到 master 分支上，将 feature 分支合并进来。

看得出来，feature 分支上的全部提交信息都会被合并到 master 分支上了，这些信息对咱们来讲不是必要的，咱们在 masetr 分支上每每只须要知道合并进来了什么新的功能便可，这些多余的信息能够经过 git rebase 的交互模式进行整合，下一节会讲到这个。

git rebase 的交互模式

打开变基的交互模式只须要传入一个参数 -i 便可，同时还须要指定对哪些提交进行处理，如：

git rebase -i HEAD~4
复制代码

上述命令指定了对当前分支的最近四次提交进行操做。下面咱们使用上面这行命令将 feature 分支的提交合并。

中间红框内有一些命令，能够用来处理某次提交的，此处咱们使用 squash 来将全部的 commit 合并成一次提交，编辑并保存以后会出现编辑提交的信息的提示，编辑提交便可。

此时再看 feature 分支上的提交记录，会看到只有一次提交了。

此时不管是直接将分支合并到 master 仍是先变基再合并，master 分支上的提交记录都会十分清爽了。

总结

当须要保留详细的合并信息的时候建议使用git merge，特别是须要将分支合并进入master分支时；当发现本身修改某个功能时，频繁进行了git commit提交时，发现其实过多的提交信息没有必要时，能够尝试git rebase。