我不知道使用 BFG 删除大/敏感文件的干净方法，并且错过了一个关键步骤：git clone --mirror git://example.com/some-big-repo.git
当我试图推动远程时，这会导致历史冲突，我天真地解决了这个问题git pull origin master --allow-unrelated-histories，合并了一些冲突，然后推动。
这重复了提交，有时重复了 5-10 次。
由于我独自处理此存储库，因此我既无法将其清理到地面并从更合理的副本重新启动，也不必担心不同的提交是不同的，我确信它们是相同的。
是否有暴力命令可以擦除除哈希之外所有方面都相同的所有提交？
是否有一个蛮力命令来擦除除哈希之外所有方面都相同的提交？
不。 但是，您可以抛弃合并提交，这是将旧历史记录和新历史记录联系在一起的原因。 这不会抹去旧的历史，但你可以停止使用它。 最终，如果你的 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'
(其中M的第一个父级是H'，M的第二个父级是H(。 你自己的 Git 中origin/master的名字是你自己的 Git 对origin的 Git 一直说的话的记忆，我的master是
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，原始命令将无处可寻。
好吧，无处可去，除了任何人曾经用它们制作过的任何其他克隆。 如果有这样的克隆，您可能需要根除它们并销毁它们，或者至少，确保你永远不会再次从中获取和合并，否则你将再次获得所有旧的提交。