git：合并和rebase之间的区别
这个问题在这里已经有了答案：
一个git rebase实际上会重播当前分支的提交，从指定分支发出的提交开始，位于指定分支的顶部。 因此，rebase会重写原始历史记录，并重新计算每次提交的哈希值，因此在您的情况下，newbr永远不会与master相偏离，因此无需执行任何操作。
但是，如果newbr已经这样提交D1，D2和D3：
D1--D2--D3 (newbr)
/
A--B--C--D--E (master)
然后你做了“git checkout newbr”，然后“get rebase master”git会重播D1，D2，然后D3在主人头上，在E的头上，你会得到这个：
(master) (newbr)
/ /
A--B--C--D--E--D1--D2--D3
所以D1的父亲现在是不同的，所以它有一个不同的散列，而不是保留分支历史的合并。 另外，请注意在执行rebase与合并时没有额外的合并提交。 希望这可以帮助。
从高级角度来看， git merge预先保存了两个分支的先前提交并添加了合并提交，所以在组合两个公共分支时应始终使用它。 git rebase抛出一个分支，将其重写在另一个分支之上，所以你应该只在私有分支上使用它。 由于它不会添加合并提交，因此在将以前的私有特性分支推送到公共存储库时， git rebase稍微可取。
在你的情况下，这两个命令是相同的，因为git merge会做一个“快进”（不需要合并提交）和git rebase会使零提交变成蓝色。 两者都具有更新newbr指向E并将其检出到工作目录的效果。