git rebase 与 merge 到底有什么区别

[bandian]

看了一下网上的答案五花八门的，我自己的理解是如果两个分支不存在冲突，那 merge 与 rebase 没有任何区别，都是按照时间顺序把提交的内容插到当前分支。

如果存在冲突，merge 会把没有冲突的节点先按时间顺序插到当前分支，再把所有出现冲突的节点后的所有提交打包，这个时候你只需要解决一次冲突，然后 git 会生成一个 merge request 的总的提交信息。

而 rebase 则是完全按照时间顺序插入到当前分支，每个出现冲突的提交都需要单独解决。

[AoEiuV020]

rebase 相当于新的提交，放弃了原来的提交，hash 变了，不再是原来那个提交了，

[bandian]

@AoEiuV020 看了一下，确实是，从 rebase 的第一个插入的提交开始，当前分支上所有提交的 hash 都改变了

[HarryQu]

https://learngitbranching.js.org/?locale=zh_CN

这个网站可以练习。

[wr516516]

@HarryQu 这个网站太好用了 我一会 rebase 用的都不是很熟练

[msg7086]

merge 会产生一个新的 merge 节点。
一般个人项目可以一路 rebase，稍微大一点点的可以按照 feature 来 merge，大公司的话可以考虑 squash merge 。

然后最主要是要分清操作的方向。
比如说你有一个主线 dev 分支，然后有各种 feature 分支。
把更改从 dev 搬到 feature 一般用 rebase，把更改从 feature 合并进主线一般用 merge 。
因为一般用 rebase，所以 conflict 应该在 rebase 的时候解决。
用 merge 解决 conflict 是很坏的习惯，因为一般习惯是 merge 本身不包含改动，只包含合并。
如果你在 merge 里偷偷藏了改动的话，需要 revert 或者 blame 或者 cherry pick 的时候就容易漏掉改动。

[zoffy]

@msg7086 #5 老哥稳，相当明白。