Question

说我在一个功能分支上，我这样做：

git fetch origin 
git merge origin/dev

我做了几次，然后一个星期后我做了：

git fetch origin
git rebase origin/dev

我之前创建的合并提交会怎样？他们会被扔掉吗？我想知道事实发生之后，rebase是否可以与merge共存。

（请注意，在这种情况下，origin / dev是集成分支）。

Answer 1

在没有-p或--preserve-merges或新的--rebase-merges选项的情况下，git rebase只是丢弃合并。

我在这里说“简单”，而“丢弃合并提交”部分很简单，但是整个过程有些复杂。关键是首先阅读并了解网站Think Like (a) Git，然后坐下来研究一系列 reachability 的示例。画一些图，例如：

       G-----H         R   <-- tip1
      /       \       /
...--F---L-----M--N--O--S   <-- tip2
      \               \
       J---K-----------P   <-- tip3

（我遗漏了Q，因为它看起来太像O。我偶然遗漏了I，哎呀。:-)）从< / em> M或P或K？当您可以查看此图或其他图形并快速枚举可实现的提交时，就可以进行下一步了。

git rebase的作用是枚举HEAD提交可以到达的那些提交，排除可以从您命名的其他提交中得到的提交。也就是说，给定git rebase origin/dev，Git会找到origin/dev可以到达的所有提交。无论其他什么情况，这些提交都将被从基础中排除。

然后，使用“不可能包含这些提交”的完整列表，Git列出了可能包含的提交的列表。这些是HEAD提交，从HEAD提交可以到达的所有提交。因此，例如，如果我们将HEAD附加到名称tip1上，则可能包含的提交是R（指向tip1的提交），O（可达R，N（可从O到达），M（可从N到达），H和L（两者均可从M访问，G（可从H访问，F（可从L和G访问）以及任何提交在F之前。

现在rebase列出了可能包括和绝对排除，Git将所有绝对排除提交扔出名单。结果是“可能包括”的较小列表。这时，默认的重新设置还会抛出所有合并提交：至少有两个父级的提交。

无论剩下什么，这些都是一个父项的提交，因此Git可以在它们上运行git cherry-pick。 Git会以分离的HEAD的形式检出--onto提交，如果未指定origin/dev，则检出目标提交（--onto），并从该列表中挑选每个提交，一次提交。这建立了新的链条。链建立后，Git将旧的分支名称移至新的HEAD提交，并且完成了基础。

合并在进行基准调整之前发生的提交

1 个答案: