Fork me on GitHub

git merge 和 rebase

rebase

假设你现在基于远程分支”origin”,创建一个叫”mywork”的分支。

1
$ git checkout -b mywork origin

在这里插入图片描述
现在我们在这个分支做一些修改,然后生成两个提交(commit).

1
2
3
4
5
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...

但是与此同时,有些人也在”origin”分支上做了一些修改并且做了提交了. 这就意味着”origin”和”mywork”这两个分支各自”前进”了,它们之间”分叉”了。
在这里插入图片描述

在这里,你可以用”pull”命令把”origin”分支上的修改拉下来并且和你的修改合并; 结果看起来就像一个新的”合并的提交”(merge commit):
在这里插入图片描述
但是,如果你想让”mywork”分支历史看起来像没有经过任何合并一样,你也许可以用 git rebase:

1
2
$ git checkout mywork
$ git rebase origin

这些命令会把你的”mywork”分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到”.git/rebase”目录中),然后把”mywork”分支更新 到最新的”origin”分支,最后把保存的这些补丁应用到”mywork”分支上。
在这里插入图片描述

当’mywork’分支更新之后,它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. (请查看 git gc)
在这里插入图片描述

现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别:
在这里插入图片描述

  • 1-2-3 是现在的分支状态
  • 这个时候从原来的master ,checkout出来一个prod分支
  • 然后master提交了4.5,prod提交了6.7
  • 这个时候master分支状态就是1-2-3-4-5,prod状态变成1-2-3-6-7
  • 如果在prod上用rebase master ,prod分支状态就成了1-2-3-4-5-6-7
  • 如果是merge 1-2-3-6-7-8 …….. |4-5|
  • 会出来一个8,这个8的提交就是把4-5合进来的提交

在rebase的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase并会让你去解决 冲突;在解决完冲突后,用”git-add”命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行:

1
$ git rebase --continue

这样git会继续应用(apply)余下的补丁。

在任何时候,你可以用–abort参数来终止rebase的行动,并且”mywork” 分支会回到rebase开始前的状态。

1
$ git rebase --abort

git pullgit pull –rebase区别

git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支,默认为merge。

git merge 和 git merge –no-ff的区别

1、尝试merge命令后,发现:merge时并没有产生一个commit。不是说merge时会产生一个merge commit吗?

1
注意:只有在冲突的时候,解决完冲突才会自动产生一个commit。

如果想在没有冲突的情况下也自动生成一个commit,记录此次合并就可以用:git merge –no-ff命令,下面用一张图来表示两者的区别:
在这里插入图片描述2、如果不加 –no-ff 则被合并的分支之前的commit都会被抹去,只会保留一个解决冲突后的 merge commit。

参考

merge和rebase