这是一个创建于 1238 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了一下网上的答案五花八门的，我自己的理解是如果两个分支不存在冲突，那 merge 与 rebase 没有任何区别，都是按照时间顺序把提交的内容插到当前分支。
如果存在冲突，merge 会把没有冲突的节点先按时间顺序插到当前分支，再把所有出现冲突的节点后的所有提交打包，这个时候你只需要解决一次冲突，然后 git 会生成一个 merge request 的总的提交信息。
而 rebase 则是完全按照时间顺序插入到当前分支，每个出现冲突的提交都需要单独解决。
 |
1
AoEiuV020 2021-06-19 12:15:04 +08:00 via Android
rebase 相当于新的提交，放弃了原来的提交，hash 变了，不再是原来那个提交了，
|
 |
2
bandian OP @AoEiuV020 看了一下，确实是，从 rebase 的第一个插入的提交开始，当前分支上所有提交的 hash 都改变了
|
 |
3
HarryQu 2021-06-19 14:51:06 +08:00  4
|
 |
5
msg7086 2021-06-19 15:49:18 +08:00 6
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 的时候就容易漏掉改动。 |
Select Language