欢迎关注富途web开发团队,缺人从众
上周花了时间把futu web博客分类,文章,入口搞了一下,主要为了解决SEO问题。接下来SEO好不好就看效果了。
今天分享的文章呢。小编觉得大家看图就行。正文讲的是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
之后发生的现象,我们首先来做一些准备工作,即创建一个项目仓库,然后在其中构建两条分支,再增加几次提交。
具体如下:
- 创建一个目录
gitTest
- 在目录
myTest
中新建一个文件readme.md
,随便添加一个标题,和第一个列表项add master1
并提交到本地仓库 - 在当前分支的基础上新建一条分支,名为
feature
,将列表项add master1
修改为add feature1
并提交到本地仓库 - 随后切换到分枝
master
上添加一个新的列表项add master2
并提交到本地仓库 - 随后切换到分枝
feature
上添加一个新的列表项add feature2
并提交到本地仓库 - 重复上面的步骤 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
。