rebasing
和 merge
都是为了将一个分支的修改合并到另外一个分支上,可是他们的实现方式不一样。
好比说,假如咱们有像下面这样的一些提交内容,merge
操做的结果像是合并了一个分支上的全部提交。而 rebase
操做将从 master 分支的最后一次提交开始添加 feature 分支中的全部更改。html
rebase
master 分支到 feature 分支,实际上是将整个 feature 分支的起点移到了 master 分支的终点Merging
获取到 feature 分支的内容并将它合并到 master 分支,最后只有 master 分支被改变了,feature 分支保持历史修改不变。Merging
会添加一个新的 commit
到历史记录里问题:在 second_branch 分支上须要 commit3 修改的内容(或者个人老大想让个人工做目录始终与 master 分支保持一致)git
这里有两种可能的实现方法:google
merge
(或者偷懒的话可使用 pull
)rebase
提醒:咱们在
second_branch
分支上进行工做以前咱们执行了git checkout second_branch
命令3d
git merge master
的结果fast-forward
(
一篇关于fast-ward
的好文档)合并的过程,所以 Git 建立了咱们称之为合并提交的方法,以将 master 分支的全部修改应用于 second_branch。
这使 git 折线图产生了一个很差看的边缘线。指针
可是,它让全部提交都与合并以前保持一致,由于它们不会更改分支的历史记录。code
注意:若是咱们从 Git 提交树上删除了(使用 rebase -i
或者 reset
)合并的提交记录(在咱们的例子中是编号:63c6403),那么来自这个被合并分支的全部提交也将从分支中撤离。
这使的代码回滚变得很是容易,当您合并了一个分支的大量提交但它们不能知足需求且必须删除它们时:只需删除 merge commit
便可。cdn
git rebase master
的结果second_branch
分支的前一个 HEAD 指针(指向当前选定分支的最后一个提交的指针)指向的是 “Commit 2”,而且经过运行
git rebase
,我但愿它的 HEAD 指针与 master 分支相同,所以,分支首先是如出一辙的,而后合并来自 second_branch 上面的提交。 这创造了一个很是好看且线性的树。
rebasing
以后会改变为 a018520,这意味着若是有人正在使用 second_branch,他将很难检索到整个新的 second_branch,由于它的树已经彻底改变了。 我认可这有点复杂,但实际上它正在将这个分支的旧的 “起点提交” 更改成 “新的” 起点。 若是您须要更好的表示方法,能够在
google 图片上查看 git rebase 的一些图形。
rebase
,何时使用 merge
?若是要同步修改的 feature 分支是和别人共同开发的分支,则不建议使用 rebase
操做,由于 rebase
会使仓库变得先后不一致。对于我的单独开发而言,rebase
操做会更有意义。htm
若是您想看到与合并操做发生以前彻底相同的历史记录,那就用 merge
吧, merge
会保存历史记录,但 rebase
会重写它。blog
rebase
更好的简化了复杂的历史记录,您能够经过交互式 rebase
更改提交历史。您能够删除不须要的提交(git rebase --onto )、将两个或多个提交压缩到一个提交中或编辑提交消息。图片
rebase
将一次显示一个提交冲突,而 merge
将一次显示全部冲突。一次显示一个提交冲突会使冲突处理的更容易,更好,可是不要忘了当有不少冲突发生时 revert
rebase 操做比 revert
merge 操做要困可贵多。
git — Basic Rebase
git-difference-between-merge-and-rebase
git-for-each-ref
Rebase vs Merge Interactive Rebase