使用 git rebase 还是 git merge，优缺点

在开发过程中使用 git rebase 还是 git merge，优缺点分别是什么？ - 知乎

看一下gerrit的模式

永远rebase 绝对禁用merge 每一个commit都是一个完整的功能 保持清晰直观的提交历史

所以，main 分支是万万不能使用 rebase 的！！！

在你打算 rebase 的时候，一定要想想是否还有别人也在开发这个分支。

适用场景

从上面的例子中不难发现，merge

和 rebase 最大的区别在于是否会保留原有的提交（或者说破坏原有的提交结构）。

merge 会对提交历史进行保留，很显然更适合多人协作开发的场景，因为如果出现问题也可以追溯到历史的每一次提交。

而 rebase 则是会让提交历史更加简洁易读，保持提交历史的线性结构，所以更适合个人开发和整理分支的情况。

如果我想要把某个特性分支 feature_xxx 合并到 main 分支中的时候，最好的方式就是 merge，而当我一个人需要开发某个 feature_xxx 分支的时候，最好的方式就是 rebase。

一句话概括就是，merge 适合团队协作，而 rebase 适合一个人开发的分支。

Git rebase详解（图解+最简单示例，一次就懂）_smartgit如何rebase到新的commit-CSDN博客

三、推荐使用场景

搞来搞去那么多，这其实是最重要的。不同公司，不同情况有不同使用场景，不过大部分情况推荐如下：

• 拉公共分支最新代码的时候使用rebase，也就是git pull -r或git pull --rebase。这样的好处很明显，我用rebase拉代码下来，但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛。

• 往公共分支上合代码的时候，使用merge。如果使用rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了。举个例子解释下，比如张三和李四从共同的节点拉出来开发，张三先开发完提交了两次然后merge上去了，李四后来开发完如果rebase上去（注意李四需要切换到自己本地的主分支，假设先pull了张三的最新改动下来，然后执行<git rebase 李四的开发分支>，然后再git push到远端），则李四的新提交变成了张三的新提交的新基底，本来李四的提交是最新的，结果最新的提交显示反而是张三的，就乱套了。

• 正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序。