Git历史重复，是否可以压缩提交？

Question

帮助：Git 历史记录重复 (O_O)

我试图获取包含 API 密钥的文件，因此研究了从 git 历史记录中删除文件并使用此处提供的命令：https://youtu.be/Bo-8EfDpKxA

我使用了命令

git filter-branch --index-filter 'git rm --cached --ignore-unmatch .env.development' HEAD git filter-branch --index-filter 'git rm --cached --ignore-unmatch .env.production' HEAD

效果很好，但我认为在将更改的历史记录拉入第二个本地存储库以测试更改时我搞砸了。我将不得不在第二个 repo 上重新定位，以确保旧的历史已经消失。但我想我已经拒绝了（快进合并或其他什么），所以现在我有大量重复的提交！ (O_O) 它们是相同的代码更改和时间戳，但提交 ID 不同。

问题

有没有办法修复历史的重复？ 历史重写将压缩每个具有相同时间戳的提交怎么样？

或者我会手动删除（几乎）每第二次提交的 rebase？

第二个问题

我在开发分支上进行了这些更改，并且文件的删除确实有效。然而，将开发合并到主人并没有成功（当然）。所以我想我也写过大师的历史吧？

但现在恐怕我会再次复制主分支历史中的提交......

Answer 1

我试图获取包含 API 密钥的文件，因此研究了从 git 历史记录中删除文件并使用此处提供的命令

您应该撤消 API 密钥并发布一个新密钥。如果 repo 在多台计算机中、由不同的人使用、备份等，那么任何类型的都是有风险的。

有办法解决吗？

我不确定您要修复什么，确切地说。任何更改提交中的任何内容的内容都会更改哈希值。因此，如果您成功删除了要删除的内容，并且现在您有一个带有旧提交的分支和一个带有新提交的分支，您需要做的是删除指向旧提交链的分支并垃圾收集存储库，以确保旧的真的消失了。

所以我想我也写了大师的历史？

分支只是指向提交的指针。如果您仍有多个包含该文件的分支，则需要移动这些分支以指向已修复的提交链。所以你必须做什么取决于。如果你的master分支也有错误，独立的，那么你也必须重写master的历史。