2

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

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

    $ git clone --mirror git://example.com/some-big-repo.git

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

    $ java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git

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

    $ cd some-big-repo.git
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive

  4. 将更改推送回远程

    $git push

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

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

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

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

4

2 回答 2

3

仍然存在于 repo 的 HEAD 的任何文件都将被保留，包括历史记录。这是为了保护你不犯错误。这个想法是您应该明确删除文件，提交删除，然后清理历史记录以将其删除。

TFS 没有gc它的回购；你的同事是对的。请参阅Team Foundation Server 2015 (tfs2015) 在 orgin/remote 上运行 git gc --prune=now进行确认。

于 2018-03-30T20:04:14.253 回答
1

不久，我还使用 BFG Repo Cleaner 从 TFS 的 git repo 中删除了一些文件夹。

如果您还想修改头部，请使用参数--no-blob-protection

显然，在清理（旧）提交中，您清理的文件丢失了。提交仍然存在，但每个相应的提交中都缺少该文件。您将无法查看文件历史记录。

出于安全原因，我总是重命名旧的 repo 并创建一个新的。甚至可能使用另一个 repo 名称，这样我的同事就不会将错误的 repo 合并到他们的工作副本中。

如果你真的想要，可以git push --all -force重写 TFS 存储库上的完整历史记录。但是，旧的历史已经一去不复返了。

于 2018-03-30T20:08:16.520 回答