git - git rebase 如何/为什么避免 merge 提交？

Question

git rebase 命令在幕后使用 merge ，所以我想知道 git rebase 如何/为什么避免 merge 提交，而 git merge 通常创建新提交如果分支之间存在差异。

Answer 1

rebase 不像 merge 分支那样 merge 。相反，rebase 是一系列 git cherry-pick。 cherry pick 接受一个提交并将其复制，就好像它是在其他提交之上编写的一样。这就像您将提交的差异应用到其他地方一样。

考虑这样一个存储库。 A、B、C 等...代表提交 ID。

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

如果 master 需要 E，也许这是一个关键的错误修复，但不是 feature 的其余部分，它可以 git cherry - 选择 E。 Git 将以 C 为原点在 D 和 E 之间进行 merge ，从而生成 E1。这就是为什么您可能会在 rebase 期间遇到 merge 冲突。但与普通 merge 不同的是，E1 将只有一个父级。

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

rebase 就像对所有提交都这样做一样。而不是在 master 之上，它移动 feature。这是 git rebase master 的样子，一步一步。

再次考虑您的存储库。

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

首先，和以前一样，它对 E 执行 cherry-pick 并将其放在 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 并将其作为 G1 放在 F1 上。

              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 访问它们。查看Maintenance and Data Recovery chapter of Pro Git了解更多。