git - rebase 和 merge 是一回事吗?为什么有 2 个不同的程序来做一件事?

标签 git version-control git-merge git-rebase

我是 git 的新手我正在尝试了解 rebase 。对我来说, merge 过程更容易理解,因为我的经验是在 Clearcase .
所以首先我无法理解 rebase 是否与 merge 完全相同。如果是,为什么同一件事有 2 个程序?
我也在阅读这部分 git-branching .
它在这里:
enter image description here

然后它说:

$ git rebase --onto master server client
This basically says, “Check out the client branch, figure out the patches from the common
ancestor of the client and server branches, and then replay them onto master.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.

所以我假设此命令意味着获取服务器和客户端分支的共同祖先之后的所有提交不包括共同祖先。所以我们得到了下一张图片。

enter image description here

然后它说:

Now you can fast-forward your master branch (see Figure 3-33):
$ git checkout master
$ git merge client

enter image description here

这个例子在我看来是错误的。
在第二张图片中我们“移动”C8C9作为 rebase 的结果.然后我们 merge 。
但是C8来自 C3C3 master 中不存在代码分支机构。
rebase之后虽然新C8C8'master 前面实际上有 master与链中的上一个一样。
但这怎么行呢?如果C8依赖于 C3 rebaseC3 以来失败不是 branch 的一部分.
例如。如果在 C3客户端使用了一些函数,它不存在于main中分支。所以在rebase之后C8'将依赖于 C3 中定义的函数main 中不存在的.所以代码无法编译。
谁能帮忙解释一下 rebase工作流程以及我在 git-scm 中对这部分教程的看法(这是错误的)是正确的吗?

最佳答案

不,这不是一回事。 rebase 会将重新设置基准的分支提交排在您重新设置基准的分支之后。

基本 merge 会创建一个新的 merge 提交结果。

我们可以说,当 merge 很明显时,rebase 避免了过多的并行分支。 但如果 merge 很复杂(处理相同的文件等), merge 会更好。 这是因为重新 merge 时,git 会重新计算差异,例如

a = b + 差异 a c= b + 差异 c

merge 是 d = a + c rebase 是 cbis = a + diff cbis

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

如果 diff 很简单,还有一个快进选项尝试在线 merge (如 rebase),如果不简单则创建 merge 。这可能是初学者的最佳选择

关于git - rebase 和 merge 是一回事吗?为什么有 2 个不同的程序来做一件事?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16724640/

相关文章:

git - 如何将我的功能分支提交更新到更新的主分支之上?

git: merge 两个分支:什么方向?

git - 我如何发布到 <me>.github.com?

sql - 在源代码管理中维护存储过程

SVN 由 1 个用户专门更改的文件列表

git - 如何在没有事件 git 安装的情况下使用 ANT 获取 git 中当前 checkout 分支的最新提交 ID?

gitattributes 没有正确设置 merge 驱动程序

git - 如何编辑 github 存储库中的初始提交?

git - 如何在推之前强制 pull

django - 如何使用 django 确保数据库更改可以轻松地通过 DVCS 移动