git rebase如何/为什么避免合并提交？

Question

该git rebase命令在后台使用了合并，所以我想知道为什么/为什么git rebase避免合并提交，而git merge通常会在分支之间存在差异时创建新的提交。

Answer 1

rebase不像合并分支那样进行合并。而是rebase一系列git cherry-pick。樱桃镐选择一个提交并将其复制，就好像它是在其他某个提交之上编写的一样。这就好比您将提交的差异应用到其他地方一样。

考虑这样的存储库。A，B，C等...表示提交ID。

A - B - C - D [master]
         \
          E - F - G [feature]

如果master需要E，也许这是一个关键的错误修复程序，但并非所有其他功能都feature可以git cherry-pick E。Git将以C为原点在D和E之间进行合并，从而得到E1。这就是为什么在重新设置基准时可能会发生合并冲突的原因。但是与普通合并不同，E1只有一个父级。

A - B - C - D - E1 [master]
         \
          E - F - G [feature]

重新设置就像是否对所有提交都执行了。而且与其处于顶峰，master不如动摇feature。这是git rebase master逐步的样子。

再次考虑您的存储库。

A - B - C - D [master]
         \
          E - F - G [feature]

首先，如前所述，它cherry-pick在E上执行一个操作，并将其放在上master。但是master，它没有移动，而是创建了一个没有标签的新分支。

              E1
             /
A - B - C - D [master]
         \
          E - F - G [feature]

然后将其插入F并将其放在E1的顶部。

              E1 - F1
             /
A - B - C - D [master]
         \
          E - F - G [feature]

然后，它挑选G并将其放在F1上作为G1。

              E1 - F1 - G1
             /
A - B - C - D [master]
         \
          E - F - G [feature]

完成樱桃采摘后，将feature分支标签移动到G1。

              E1 - F1 - G1 [feature]
             /
A - B - C - D [master]
         \
          E - F - G

是的，旧的提交仍然存在。如果没有引用它们的信息（例如标签或其他分支），则将在几周内将其回收。同时，您仍然可以使用访问它们git reflog。有关更多信息，请参见Pro Git的“ 维护和数据恢复”一章。

Answer 2

您可以这样想：git rebase从您的分支中获取新的提交并将其放在一边，然后倒回您的分支以匹配更新的原始分支，最后将您的提交添加到结果之上；git merge只需创建一个新的（合并）提交，其中包含分支之间的差异。请注意，在重新设置原始分支上不存在的所有提交的情况下，它们的哈希值将发生变化，因此您将不得不强制推送新分支（如果有多个人在同一个分支上协作，这并不总是那么容易）分支）。然而，变基可以让您避免合并提交并保持更清晰的历史记录。