有很多关于如何更改git提交的作者/电子邮件的帖子，但根据我的理解和观察，所有这些帖子都只是用调整后的用户信息创建一个新的提交，但实际上并没有删除旧的提交。
情况是这样的。将代码提交到我们的存储库的人是git的新手，并且错误地设置了他的全局git配置，因此设置为以该用户的电子邮件地址为名称，以他的电子邮件密码为电子邮件地址，而不是该用户的名称和电子邮件地址。
当然，那个人后来更改了密码，但它仍然在回购中徘徊，我们想修复那个人的提交。不幸的是，在他推送之前，没有人知道它是如何在他的开发PC上设置的，现在它在GitLab中可以看到所有这些提交。
我们已经尝试了各种各样的东西，比如git filter-branch --env-filter、git replace、git rebase，基本上，当你按照"；更改git提交作者"在这一点上，树枝似乎相对干净。没有一个"；被污染的"；提交仍在该分支中，但它们仍在某个的repo中。例如，在一台dev PC上，git log --reflog | grep "ROGUE PASSWORD"仍然显示了几个结果。即使他们不在分支中，如果有人浏览git log --reflog，他们仍然可以在那里的某个地方看到它，你可以将这些提交哈希放入GitLab，仍然可以找到它们。
似乎真的没有办法解决这个问题。。。也就是说，您可以对提交进行混洗并修复分支，但git似乎无法真正删除提交及其所有元数据(这可能不是真的，如果是，则通常没有必要，所以可能很难找到该选项的文档？)。在某种程度上，这没关系……就像我说的，他后来更改了密码。但是，在我们的头撞墙几个小时后，我们必须知道：这能解决吗？如果我有一个与错误名称/电子邮件相关的所有提交哈希的列表，有没有办法真正地将它们从repo中删除？
Git提交编号(SHA-1哈希)由提交对象的内容组成。提交对象包含以下信息：
- 树对象的SHA-1哈希，包含附加到提交的文件版本
- 父提交的SHA-1哈希
- 作者姓名和电子邮件
- 日期和时间
- 提交邮件
更改其中任何一个都将产生新的SHA-1哈希。
有关此方面的更多信息，请参阅：https://git-scm.com/book/en/v2/Git-Internals-Git-Objects.
存储库中的分支和标记应该指向所有先前的提交；值"；在项目中，直接或通过分支或标记指向的提交的父提交链。
孤立的提交可能由于各种原因而发生，例如重新建立基础、删除旧的分支等。孤立的分支和提交在不再由分支或标记直接指向或通过父提交链指向后可能会持续一段时间，但不应该是一个问题，因为它们的孤立表明它们不再具有"孤立"；值"；。此外，远程存储库将定期清理这些提交以回收空间，除非用户明确地从远程存储库获取提交，否则这些提交不会出现在本地存储库中。
如果确实担心将提交保存在存储库中，例如当它可能包含敏感信息、脏话等时，可以使用git gc(https://git-scm.com/docs/git-gc)，但请注意，这将删除本地存储库中的所有孤立分支和提交。要在远程存储库(例如Bitbucket或Github)上执行此操作，您需要参考有关如何强制服务器进行垃圾收集的平台文档。通常，不建议在远程服务器上进行垃圾收集，因为这可能会在需要时阻止项目的恢复，并且考虑到大多数服务器将定期运行垃圾收集以删除长期孤立的提交。
TL；DR
耐心一点，即使是看似孤立的提交也需要几个月的时间才能收集到垃圾。
或者在您所知道的每个沙箱和服务器实例中运行git gc --aggressive。
详细信息
这是一个棘手的情况，因为任何在提交时克隆您的repo或从中提取repo的人都将拥有本地副本。
孤立的提交最终会在运行垃圾收集时被删除，但在提交真正成为孤立之前可能需要很长时间(甚至可能永远)：任何指向这些提交的分支、标记、PR、问题或其他任何东西都会使其保持活力。因此，要真正孤立提交，您需要删除任何引用它的内容。
即使你没有任何指向提交的东西，仍然有reflog：它的默认保留期为90天，在某人的沙箱中的reflog中找不到的任何提交都不会被垃圾收集：如果它可以从reflog中的一个条目访问，它仍然不是孤立的！
您可以耐心等待，最终这些提交将从reflog中掉出来并被收集垃圾。由于用户更改了密码，这可能就足够了。
或者你可以不那么耐心，在每个人的沙盒中运行git gc --aggressive。但这可能会清除他们以后希望仍然可以访问的东西。当然，只有当他们没有任何挥之不去的当地分支机构或指向不良历史的标签时，这才会有效。
您需要参考服务器的文档，以了解如何在那里执行等效命令，请记住，您提交PR/MR的分支机构可能会永远保留在服务器上。
要想真正清理服务器端，你可能需要创建一个新的回购，并将好的分支和标签推到它上面，但这意味着失去你的问题和公关历史等等。