rebase和合并是一样的吗？为什么有两种不同的程序可以做一件事？

Question

我是git的新手，我正在努力了解这一点。对我来说，合并过程更容易理解，因为我的经验是Clearcase 首先，我无法理解rebase是否与merge完全相同。如果这就是为什么同一件事有两个程序？
我也是从git-branching阅读这部分内容 它在这里：

然后它说：

  

$ git rebase - 主服务器客户端
  这基本上说，“检查   离开客户端分支，找出常见的补丁   客户端和服务器分支的祖先，然后重播它们   主人。“这有点复杂;但结果如图3-32所示，   非常酷。

所以我假设这个命令意味着在服务器和客户端分支的共同祖先之后接受所有提交排除共同的祖先。所以我们最终得到了下一张图片。

然后它说：

  

现在你可以快进你的主分支（见图3-33）：
  $ git checkout master
  $ git merge client

这个例子对我来说似乎不对 在第二张图片中，我们“移动”C8和C9作为rebase的结果。然后我们合并。
但是C8 C3来自C3并且master代码中没有rebase代码。
在C8之后C8' master，master位于C8之前，实际上C3位于链中。{
但这怎么可行呢？如果rebase取决于C3，则branch会失败，因为C3不属于main。
例如。如果在rebase中有一些客户端使用的函数，它在C8'分支中不存在。因此C3之后main将rebase中git-scm中定义的{{1}}中定义的函数具有依赖关系。所以代码不会编译 任何人都可以帮助解释{{1}}工作流程，以及我对{{1}}中这部分教程的说法是否正确（

Answer 1

不，这不是一回事。 rebase将把重新分支的分支提交到你重新分支的分支之后。

基本合并将创建合并的新提交结果。

我们可以说，当合并很明显时，rebase避免了太多的并行分支。 但是如果合并很复杂（处理相同的文件等），合并会更好。 这是因为在重新出现时，git重新计算差异，比如

a = b + diff a c = b + diff c

合并是d = a + c rebase是cbis = a + diff cbis

和diff c可能很容易阅读， diff cplus可能很复杂

还有快进选项，如果diff很简单，则尝试合并（如rebase），如果不是，则创建合并。这对初学者来说可能是最好的