Git Merge Fast-Forward vs Git Rebase答案

【问题标题】：Git Merge Fast-Forward vs Git RebaseGit Merge Fast-Forward vs Git Rebase
【发布时间】：2022-01-07 22:16:56
【问题描述】：

快进git merge 和git rebase 有什么区别？不要既保持历史线性又没有合并提交？如果是这样，为什么一个人会使用另一种呢？如果不是，我认为这是真的，我没有看到的整个故事是什么？

谢谢！

【问题讨论】：

它们完全不同。
合并（在一般情况下）产生分支合并历史。作为一种特殊情况，Git 所谓的 fast-forward 合并（根本不是合并）并没有。既然这就是你要问的——快进——他们最终会做同样的事情。
@torek，所以快进和变基做同样的事情？
不是一般情况，但对于这种特殊情况是的。
啊，好的。是时候了解一下快进了。

【解决方案1】：

当你领先于主人时，两者都做同样的事情。

如果你领先和落后于 master，那么快进合并是不可能的，因为 master 上有更新的提交。但在这种情况下，您可以变基，根据在 master 之前的提交创建新的提交。

当你领先于主人时：

            *E-*F-*G-*H-*I    BRANCH
           /
*A-*B-*C-*D                   MAIN

当您进行快进合并时，主指针会向前移动到分支的顶端。当你变基时，分支的每个提交都会移动到 MAIN 的头部之后。最终结果是一样的：

*A-*B-*C-*D-*E-*F-*G-*H-*I MAIN | BRANCH

当你在 MAIN 的前面和后面时：

            *E-*F-*G-*H-*I    BRANCH
           /
*A-*B-*C-*D-*J-*K             MAIN

那么你不能快进将 E..I 合并到 main 中，因为 J..K 在路上。所以在这种情况下快进是不可能的。

但你可以将 E..I 重新设置为 K：

*A-*B-*C-*D-*J-*K-*E'-*F'-*G'-*H'-*I'             MAIN | BRANCH

但是会发生什么是包含 E 的更改并附加到 main 的新提交，然后使用 F 的更改进行新的提交并附加到 main... 等等，直到分支的所有提交都有在另一个分支上被“移动”/“重播”。结果又是一条没有分支和合并的历史记录。

由于必须重新应用提交并且冲突可能已解决，因此实际提交将发生变化，生成新的提交 ID 等等。

【讨论】：