当前状态：我将带有内部数据库凭据的文件提交到我的 Git 存储库。这很好，因为我只单独使用它。然后我的团队开始在这个项目中进行克隆、推送和拉取。我们现在有几个 Git 存储库（一个中央存储库和一些开发人员）。
问题：我们现在想要公开访问源代码和 Git 存储库，或者至少让 Git 管理其他贡献代码的人的详细信息。
问题：什么是一个好的策略
a) 从中央或所有存储库中删除带有凭据的文件，或
b) 建立一个新的 Git 存储库作为与外部世界的“接口”？
如果选择 (b)，我们如何轻松地将更改传达回主存储库？
由于已经广泛分布，我们真的不想在每个当前存储库上执行 agit rebase或 a 。git filter-branch
抱歉，git filter-branch如果您想从主存储库中删除凭据，您将无法运行。请参阅GitHub 上的人员编写的删除敏感数据。
由于 git 的设计，无法强制现有克隆从其各自的历史记录中删除文件。
您可以清理单个分支并使其成为未来开发的基础：
$ git checkout -b old-master master
$ git filter-branch ... master
现在您需要将经过清理的 master 推送到仅包含 clean master 的新仓库：
$ git push new-central master
如有必要，现有存储库可以将新的远程和git cherry-pick更改从其旧分支添加到新的干净主控。
对于新的存储库，设置某种屏障以防止有人将敏感数据推送到它，这样您就不会再次遇到同样的问题。这个障碍可能是一个人，他控制着新的中央存储库并审查所有补丁以决定进入什么。
只需更改您的内部数据库的密码，以及具有相同密码的任何其他服务。（对于您历史记录中存在的任何其他密码也是如此）。
如果不使用 rebase 或 filter-branch，您将无法做到 a)。但我想说，现在这样做可能比永远隐藏历史要好得多。我猜b）可以通过在删除凭据的提交后拆分历史来完成。结果几乎是两个历史记录，放在两个不同的存储库中；一个在清理之前，一个在之后“重新启动”。这两个回购的历史可以通过那些需要到达旧历史的人的回购中的嫁接点来连接。
无论哪种方式，您都将不得不处理大量的 sh*t，我建议您选择 a) 和 filter-branch，即使它需要做很多工作。
所以，我们已经完成了，我想分享我们最终是如何做到的。
我们很幸运，在某个时刻没有人拥有自定义分支。所以我们基本上所做的是，最后一次将他们的东西推送到中央存储库。
然后我们使用filter-branch了 GitHub 工作人员所描述的方法。然后我们就有了一个清晰的中央存储库。
最后（这只是因为没有提到的本地分支）我们删除了我们的本地存储库并从现在干净的中央存储库中克隆了新的存储库。
简而言之：这种方式是一个非常快速和无痛的过程。不优雅，但它有效。