关于Git的合并与变革

Question

以上是合并和rebase的结果.

我的问题是,在最终状态下,C5和C3'是否相同？

或者说,git rebase等于git merge+删除C3？

Answer 1

这个例子不是很好,因为它只考虑一个提交(合并或重新绑定),让你觉得结果提交是相似的.通常,rebase将添加多个提交,而合并将添加最多一个(快进合并添加无).

而且,只要没有要解决的冲突,或者每次都以相同的方式解决所述冲突,C3'和C5的最终内容将是相同的但它们仍然是不同的提交(因为C3'和C5有不同的父母,他们也会有不同的哈希,这个事实在下面的插图中更为明显.相应地,每个记录的历史记录是不同的.对于rebase的注释,历史是线性的,而对于合并,它是一个晶格.

合并/重新定位几个提交时,请考虑相同的问题,如Mark Lodato的" A Visual Git Reference "所示.你会看到最终的结果是完全不同的.

git checkout master
git merge other # update master with tip of branch 'other' changes

你只需:

• 在当前提交(ed489下面,因为你是在主),
• branch other的最新提交(这是一个快照,表示在' other'中分支时的repo的全部内容,而不是delta)
• 他们的共同祖先(b325c),并执行三向合并.

有关此图中工作目录和阶段的含义,请注意进入三向合并的箭头,然后是工作目录和阶段.工作目录表示您看到的所有文件(在您的硬盘驱动器上),其中一些文件由于三向合并而被更改.该阶段保存由三向合并更改的文件,然后用于创建新提交(f8bc5).

这与rebase非常不同,后者努力在目标分支的顶部重新应用每个分支的提交:

git checkout topic # this time we are on topic
git rebase master  # means: recreate every topic commits on top of master
                           at the end, we are still on (new) 'topic' branch

上面的命令接受' topic'但不在master(即169a6和2c33a)中的所有提交,将它们重放到master,然后将分支头移动到新的提示.请注意,如果不再引用旧提交,则最终将[最终]进行垃圾回收.

重新使用工作目录和暂存区域,因为它重放提交(将更改应用于工作目录,将更改添加到暂存区域,提交暂存的更改,重复).完成所有这些后,重新分支的分支头被设置为最后一个新提交(f7e63).

另外2个差异:

• 合并和rebase服务于不同的工作流程:请参阅" git merge与rebase "
• 合并与变革之间的"我们的"和"他们的"是不同的:" 为什么"我们的"和"他们的"的意思被颠倒了 "