问题标签 [bfg-repo-cleaner]

我最近使用 BFG --delete-files 从存储库中删除了几个大文件，输出似乎符合我的预期。正确的文件和大小被报告为从 repo 中删除，并且本地大小反映了这些删除。

但是，当我上传并与 master 比较时，它报告说存在巨大差异，并且影响了数百个提交。我不知道该怎么做或如何理解它；经历太多了。我知道删除文件将重组 repo，但我如何确定差异中实际发生了什么？

我最近注意到我不小心提交了一个.env包含敏感信息的文件。我最好的猜测是，当 Webstorm 询问我是否要将文件添加到 git 时，我不小心单击了确定，因为它是.gitignore在创建后立即添加到文件中的。我没有注意到这个文件连续几周被推送到 VCS。我立即运行git rm --cached .env并使用了BFG-Repo Cleaner从我的版本历史记录中清除文件。问题是，虽然 BFG-Repo Cleaner 完成了它的工作（虽然奇怪的是，现在每个提交都是重复的），并且该文件在我的提交历史记录中不再存在，但我实际删除文件的提交显示了删除的确切内容，即密码和密钥。这是运行 BFG-Repo Cleaner 的常见结果吗？如果是这样，我怎样才能从历史记录中删除该提交而不会丢失此后所做的任何提交？我能找到的大多数答案都是指使用git reset --hard恢复到我想要摆脱的提交之前的提交，但我不希望在那之后失去我的工作。

我只是觉得奇怪的是，设计用于从版本历史记录中删除敏感数据的工具仍然会显示删除敏感数据diff的提交。

我使用了 BFG-Repo-Cleaner，因为它似乎是一个更简单的替代方案git-filter-branch，但是现在是否有一个用例可以git-filter-branch在这里使用，不是删除文件，而是删除显示我删除的文件内容的提交？

我有一个开源项目，我做了大量工作并经常推送到内部存储库。

该项目中的前端代码被转换为单个 javascript 文件，其更改是每次提交的一部分。（顺便说一句，在我转译和缩小文件后，它的大小大约为 3MB）

当我准备将我的所有提交推送到开源社区 (Github) 时，该文件的总提交大于 100MB。由于这些提交的总大小大于 100MB，Github 不允许我推送所有更改。

作为一种解决方法，我一直在使用BFG从所有提交中删除这个文件，除了最新的提交。有没有更好的解决方案来解决这个问题？在推送到开源（Github）之前，我仍然需要能够在内部多次提交。

我的 git 历史记录中有很多 jar 文件，而且占用了大量空间。我可以使用 BFG Repo Cleaner 从我的历史记录中删除所有 jar 文件吗？

我认为运行这样的--delete-files命令bfg --delete-files .jar <git repo name>.git，但我不确定。

这是正确的方法吗？如果没有，如何从我的历史记录中删除所有 jar 文件？

谢谢。

有没有办法在不使用 BFG 且不删除文件历史记录的情况下替换 git repo 中的敏感信息（API 密钥等）？

BFG 依赖于 JRE，如果有其他方法，我真的不想安装它。

Github 帮助页面建议使用 filter-branch 但由于这是我的应用程序 api 的主要路由文件，我想保留它的更改。

一位开发人员认为将应用程序的安装文件放入团队在 TFS 中共享的 GIT 存储库中是一个好主意。所以我试图在 GIT 存储库中删除一个名为“Workstation Install”的文件夹，以便删除所有安装文件，然后修复现在大约 1.6GB 的包文件。

我试过 BFG Repo-Cleaner 和 Git Extensions。Git Extensions 以查看在运行 BFG 步骤后该文件夹是否仍然存在。

我对 GIT 真的很陌生，大约一年前，在我开始工作并发现问题之前，这 28 个文件被放入了 repo。

有关如何执行此操作的任何帮助或步骤。

不知道如何为 BFG 执行此操作：默认情况下，HEAD 分支受到保护，虽然它的历史记录将被清除，但最近的提交（“提示”）是受保护的提交，其文件层次结构不会完全改变。

我的存储库中的一个巨大文件夹已经填满了我的 LFS。按照此处的说明，我希望从远程存储库中删除该文件夹，然后重写历史记录以将其从所有先前的提交中删除。这应该在我的 LFS 中释放大量空间，但不是。我错过了什么？

假设存储库是repo并且有问题的文件夹是repo/unwantedFolder.

我做了以下步骤：

1. 删除了不需要的文件夹并重新提交：

   /li>

2. 镜像克隆 repo：

   /li>

3. 重写历史：

   /li>
4. 移入操纵的克隆回购：$ cd repo.git/

5. 使用 git gc 命令：

   /li>
6. 推送干净的存储库：$ git push origin
7. 移回原始存储库：$ cd repo/
8. 从 github 拉取：$ git pull origin master

虽然一切似乎都运行良好，但当我检查 github 中的旧提交时，不需要的文件夹 / 仍然出现在那里！

我错过了什么？

我打算在存储库上问这个，但 SO 似乎是一个更合适的地方问这个。

我能够使用 BFG Repo Cleaner（很棒的工具，谢谢！）将我们的.git文件夹大小减少了 1GB 以上，就我们的存储库而言，这是一个巨大的成功。我还没有将我的裸克隆推送到远程，因为我担心在了解推送而不重新克隆的后果之前提出这些更改。

我知道最佳实践表明，当历史以这种方式发生变化时，最好的解决方案是执行新的克隆。然而，我与一个超过 50 人的团队一起工作，他们拥有超过 2GB 和 23k 次提交的存储库，在我们的结构下，跨团队协调可能非常困难。结果，我有一些问题：

1. 如果我推送这些更改的 refs，而人们要拉到他们现有的副本而不是创建一个新的克隆，后果会是什么？
2. 如果可行的话，他们是否需要做任何其他事情来减轻这些后果，作为拉动的一部分，或者除了拉动之外？
3. 如果您认为已删除的 blob 来自至少一年且最多三年的历史，那么此建议是否会发生变化？
4. 最后，鉴于新的克隆不会包含任何未在上游同步的工作，您是否有关于将未跟踪的分支从一个克隆转移到另一个克隆的最佳方法的建议？如果已经存在执行此操作的 Git 命令，我很想听听您的见解。

再次感谢您创建了如此方便的工具，希望我能完成使其对我团队的项目有用。与此同时，我将继续在我的叉子上进行实验。

BFG Repo Cleaner站点提供了一个使用该工具清理存储库的示例，如下所示：

1. 克隆你的 repo 的新副本。

   /li>

2. 运行 BFG 来清理你的 repo。

   /li>

3. 使用 git gc 去除不需要的脏数据

   /li>

4. 将更改推送回远程

   /li>

我了解头分支受到保护，因此头分支中大于 100M 的任何文件仍然存在。如果我按照描述运行此工具，我将丢失所述 100M 文件的任何历史记录，对吗？因此，如果旧提交中有该文件的旧版本，它就消失了，我将无法在以前的状态下使用它....对吗？

另外，我有一位同事陈述了以下内容，我想知道这是否属实：

如果您推回在 TFS 中镜像的存储库，则对您的包文件的更改将不会反映在远程和未来的克隆上

您必须在 TFS 中创建一个新存储库并将镜像推送到那里，以便远程选择包文件更改。

我想从 git 存储库中删除大量单元测试文件，并将它们从提交历史记录中擦除，以节省空间。我知道这样做的两种主要方法是使用 git filter-branch 或使用 BFG repo 清洁器（由Roberto编写。）

1) 假设主 repo 已经被清理并且团队成员没有删除他们旧的脏版本 repo。如果他们执行 git pull --rebase，然后推送到主仓库，历史还会变脏吗？

2) 如上所述，假设主 repo 已被清理，并且团队成员尚未删除他们旧的脏版本 repo。假设团队成员推送到主仓库。我怎么能知道团队成员使用了他们肮脏版本的 repo 进行了推送？（我是否必须只比较该提交的父级的提交哈希？我的理解是，无论是通过 BFG 还是 git filter-branch 清理主仓库都会更改仓库中所有提交的所有哈希）