Question

我有一个非常奇怪的问题。在尝试迁移到Github的大型文件存储并且试图从中迁移之后出现了一些不幸，我现在有一个非常混乱的git拓扑，看起来像这样：

A  - B  - C - D - E - F 
            /
A' - B' - C'

现在，C与C＆＃39;完全相同，B与B＆＃39;完全相同，所以一直回到初始提交。如果我做＆＃34; git log＆＃34;，我基本上会看到在D. D本身是空合并之前对所有内容的重复提交。

有没有办法彻底删除A＆＃39;，B＆＃39;和C＆＃39;，以便我的历史记录如下？

A - B - C - E - F

Answer 1

是。您可以将E - F重新定位到C。

git rebase --onto <new-base> <exclusive-start> <inclusive-end>

由于起始点是独占（它不会被重新定位），我们从D开始并以F结束。（这样可以很容易地重新分支在分支顶部的分支）。

git rebase --onto C D F

你会结束这件事。

            E' - F'
           /
A  - B  - C - D - E - F 
            /
A' - B' - C'

只要没有提到F，A' - F最终将被垃圾收集。

Answer 2

鉴于D没有引入任何更改，有几种方法可以做到。

一个rebase将起作用（正如Schwern建议的那样）。＆＃34;重排根目录＆＃34;也会有效。

因为rebase更熟悉＆＃34;，我认为有些人可能更喜欢这种方法。另一方面，在某些情况下，变基数变得复杂可能会引入错误;出于这个原因，我希望在两者预期相同的情况下重新定位。

假设您显示的历史记录是master分支的历史记录（并且从D开始没有任何内容可以从任何其他分支到达），那么rebase将是

git rebase --onto C D master

将C和D替换为解析相应提交的表达式（即提交ID，或者在您显示的历史记录图表中为master~3 C。

请注意，我使用分支名称而不是提交ID或其他表达式来标识F。这样，rebase操作将自动移动分支。

如果在D之后有合并（即使它们全部折叠回一个仍然是当前的分支），或者如果有多个分支指向您正在移动的历史记录，那么这些是最明显的情况，你可能会考虑重新定位。

在这种情况下，您使用git filter-branch。有几种方法可以做到;查看git filter-branch下的parent-filter文档（https://git-scm.com/docs/git-filter-branch）;有些示例明确说明了如何重新生成提交。