BFG（历史记录编辑）后，所有提交都重复

Question

我不知道使用BFG删除大文件/敏感文件的干净方法，错过了关键步骤： git clone --mirror git://example.com/some-big-repo.git

当我尝试将其推送到远程站点时，会导致历史冲突，我天真地解决 git pull origin master --allow-unrelated-histories了这些冲突，合并了一些冲突，然后再进行推送。

这重复了提交，有时是5-10次。

由于我一个人在做这个仓库，所以我既没有选择清理这个仓库并从一个更合理的副本开始重新启动的选择，也没有必要担心不同的提交是不同的，我确信它们是相同的。

是否有蛮力命令擦除所有在哈希表以外所有相同的提交？

Answer 1

是否有蛮力命令擦除所有在哈希表以外所有相同的提交？

不可以。但是，您可以放弃您的合并提交，这就是将旧历史和新历史联系在一起的原因。那不会清除旧的历史，但是您可以停止使用它。最终，如果您的Git找不到它，它将消失。

您需要做的是git reset --hard在自己的存储库上运行（丢弃一个合并提交），然后使用git push -f将所有内容发送到origin并让它们移动它们 master。

两种不同的提交哈希ID是两个不同的提交，这是不可能改变任何事情任何承诺。这就是BFG（和Git自己的git filter-branch）复制所有提交的原因：它们实际上不能更改旧的提交。这就是您获得所有内容的两个副本的方式。

首先，您制作了新的副本，并将旧的副本扔给了新的副本。那就是BFG所做的。（这git filter-branch并不能完全解决问题：它不会扔掉旧的，只是将它们推到一边，然后让您扔掉它们。）

到目前为止，一切都很好。但是随后您跑去git fetch拿起所有旧提交，然后git merge选择：现在将旧提交和新提交粉碎在一起，即使它们之间没有关系。

如果您的新旧提交历史非常简单，我们可以这样绘制它们：

A--B--...--H   <-- origin/master

A'-B'-...--H'  <-- master

（大写字母代表提交哈希，例如，A'撇号（而不是A）表示质点已更改），这就是为什么它们具有不同的哈希的原因。）大概您的历史（您的提交）更加复杂，但是这种表示仍然足够：只涉及一个原始的端点提交（例如H）和一个新的端点提交H'（）。

您最后停留的合并会执行以下操作：

A--B--...--H    <-- origin/master
            \
             M   <-- master
            /
A'-B'-...--H'

（其中的第一个亲本MIS H'和的第二个亲本M是H）。origin/master您自己的Git中的名称是您自己的Git对originGit一直在说的话的记忆，我master是<h的哈希>：他们仍在记住commit H作为他们的master。

如果您从自己分支的尖端删除 commit ，那么您将在自己的存储库中保留以下内容：Mmaster

A--B--...--H    <-- origin/master
            \
             M   [abandoned]
            /
A'-B'-...--H'   <-- master

提交M仍然存在，但是您再也看不到它了：没有找到它的简便方法。如果您决定退货，不容易找到它的方法会将其保留至少30天，但最终，它们会让它掉下来并真正消失。

现在，您可以运行：

git push --force origin master

有你的Git调用origin的混帐，确保他们有各种各样的改写提交（A'-...-H'），然后发送形式的有力命令：是的，这会让你在访问提交H，但设置你的master指向承诺H'，而不是。 他们通常会遵守此命令-如果不这样做，则必须找出为什么不这样做（例如，GitHub的“受保护的分支”功能）并首先解决该问题 -然后它们将具有：

A--B--...--H   [abandoned]

A'-B'-...--H'  <-- master

（假设您从未发送过这些邮件M-如果您这样做了，他们也会收到，但同样会被丢弃）。您的Git将看到他们遵守了此命令，并将更新您的 命令origin/master以反映该命令：

A--B--...--H   [abandoned]
            \
             M   [abandoned]
            /
A'-B'-...--H'   <-- master, origin/master

当足够的时间到期时（通常对于裸服务器存储库（例如，在GitHub上的存储库）而言，时间要短得多，但是在您自己的存储库中则需要30天以上的时间），当Git的垃圾收集器运行并清理时，废弃的提交将被垃圾清除。在这一点上，没有人会记住原始的哈希ID，也找不到原始的命令。

好吧，无处可去，除了任何其他人克隆过的克隆。如果有这样的克隆，你可能需要根出来，并摧毁它们，或者至少，以后就不会再读取和合并从他们再次，否则你会回来拿到所有的老提交一次。