git中merge和rebase

Posted 2023-04-28

参考技术A git中的merge和rebase都有合并的功能，但是他们之间存在区别，有不同的使用场景。
比如当前在master分支，master中有A,B,C,D四个提交，dev分支中有两个提交M和N，现在需要将dev分支合并过来，那么可以通过命令

从上面两张图我们可以看出他们之间的区别，merge会创建一个新的节点，之前的提交分开显示，而rebase操作不会生成新的节点，是将两个分支融合成一个线性的分支，顺序为commit的时间顺序。

git中merge和rebase的区别

1.采用merge和rebase后，git log的区别，merge命令不会保留merge的分支的commit：
2.处理冲突的方式：
·（一股脑）使用merge命令合并分支，解决完冲突，执行git add .和git commit -m’fix conflict’。这个时候会产生一个commit。
·（交互式）使用rebase命令合并分支，解决完冲突，执行git add .和git rebase --continue，不会产生额外的commit。这样的好处是，‘干净’，分支上不会有无意义的解决分支的commit；坏处，如果合并的分支中存在多个commit，需要重复处理多次冲突。
3.git pull和git pull --rebase区别：git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支，默认为merge。

举个例子：
假设我们现在有3个分支
master分支：线上环境使用的分支
testing分支：测试环境使用的分支
my_feature分支：开发新功能的分支，也就是当前分支

A. 假设我在my_feature上开发了一段时间，之后另外的同事开发的功能正式上线到master分支了，那么我可以在当前的分支下rebase一下master分支，这样我这个分支的几个commits相对于master还是处于最顶端的，也就是说rebase主要用来跟上游同步，同时把自己的修改顶到最上面
B. 我在my_feature上开发了一段时间了，想要放到testing分支上，那就切到testing，然后merge my_feature进来，因为是个测试分支，commits的顺序无所谓，也就没必要用rebase (当然你也可以用rebase)