9

我对整个存储库（仅由我使用）感到非常厌烦，并且可以使用一些帮助来整理它。

这就是我所做的。我意识到在我的提交历史中，有一些文件包含我不想随便放置的凭据。因此，我决定合法并尝试使用 BFG Repo-Cleaner 来解决这些问题。我将所有凭据都放入 .gitignores 中，然后继续尝试将它们从历史记录中删除。根据文档说明，我执行了以下命令：

git clone --mirror myrepo.git
java -jar bfg.jar --delete-files stuffthatshouldbedeleted.txt  myrepo.git

此时，BFG 告诉我已经找到并删除了 x 个文件。甜的。

cd myrepo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push

根据终端日志，它更新了 repo。到目前为止一切顺利，对吧？我进入我的 github 帐户，单击几下后，在我的历史记录中找到仍然存在的凭据、文件和所有内容。我回去尝试相同的命令集，但使用这一行而不是文件删除器：

java -jar bfg.jar --replace-text passwords.txt  myrepo.git

其中 passwords.txt 是一个文件，其中包含我想要的所有凭据的字符串实例。同样，BFG 日志表明它已经修复了几个实例。我向上推，检查，证书还在，坐在 Github 上。我注意到我所有提交的 SHA-1 密钥都已更改，所以大概 BFG 做了一些事情，而不是我想要它做的事情。

在这一点上，我放弃并尝试重新开始工作，我想我稍后会解决它。我做了一些工作，尝试向上推，得到一个奇怪的合并冲突（你在提交时领先 50 和落后 50）。什么？我尝试拉取和合并，突然间，我的 git 历史记录中的每一个提交都在名称上重复，其中一些只是空白。我检查了我的 Github 网络图，看起来从我的初始提交开始有第二个分支，它完全反映了我上次提交时压缩的所有提交（我从未分支过，只是一直在线性增长）。

我无法恢复到以前的提交，因为它们都是按时间顺序重复的。我的凭证仍然在那里，现在有两倍多的实例，我的历史翻了一番，而且很难理解。当我现在尝试从头开始运行 BFG，重新克隆和镜像 repo 时，它告诉我其中没有凭据，尽管我可以在 Github 中看到它们。我真的可以使用一些帮助来理解发生了什么，以及如何（如果有的话）再次回到原来的状态。

我正在考虑删除整个回购并重新开始。我真的不想那样做。

tldr; 尝试使用 BFG，以某种方式复制了我的 repo 中所有提交的半生不熟的版本，无法解开，并且雪上加霜，BFG 什么也没做，并声称它已经完成了它的工作。

4

1 回答 1

23

我是 BFG 的作者，我将尝试根据您的帐户逐步描述我认为发生的事情：

BFG前手动清洗...

首先你：

将所有凭据都放入 .gitignores 中，然后继续尝试将它们从历史记录中删除。

您的操作的此描述省略了两个基本步骤：

  1. 从您当前的文件树中手动删除凭据，并将该更改提交到您的存储库。如果您不这样做，BFG 会从您的旧提交中删除内容，但会保护您当前提交中的污垢。此行为在 BFG 文档中标题为“您当前的文件是神圣的... ”的部分下进行了介绍，如果您忘记这样做，BFG 会在您运行它时打印一条警告消息（“警告：上面的脏内容可能从其他提交中删除，但由于受保护的提交仍在使用它，它仍将存在于您的存储库中...... “等）。您在运行 BFG 时是否看到该消息？

  2. 在克隆存储库的完整镜像之前，需要将该提交推送到您的 GitHub 存储库。你忘了那一步吗？

如果您没有做这些事情，那将说明您的凭据没有从您的存储库中完全清除。

第一次运行 BFG...

继续，然后你：

  • 从 GitHub 对你的 repo 做了一个全新的镜像克隆
  • 运行 BFG，使用该--delete-files选项进行过滤（您是否看到受保护的内容警告？）
  • 将更新的存储库推送到 GitHub

...此时：

根据终端日志，它更新了 repo。到目前为止一切顺利，对吧？我进入我的 github 帐户，单击几下后，在我的历史记录中找到仍然存在的凭据、文件和所有内容

因此，假设您在运行 BFG之前正确地从最新提交中手动删除了不良内容，那么您所看到的就相当奇怪了。一些可能的原因：

a) 存储库未使用--mirror标志克隆，因此并非 GitHub 上的所有分支都被覆盖，在非主分支中留下脏历史。但是，您已明确声明您使用了该--mirror标志。

b) 即使镜像推送到 GitHub，旧的提交在被显式提交 ID（即其中包含提交 ID 的 GitHub url）引用时仍然可用，直到GitHub 运行它的自动垃圾收集你的存储库。拉取请求和分叉还可以保留来自旧历史的提交。这将是您看到的脏提交的另一种可能解释。

第二次运行BFG...

无论如何，那时您很担心，并且：

  • 再次运行 BFG，这次使用--replace-text passwords.txt更新文件内容而不是删除整个文件。

同样，BFG 日志表明它已经修复了几个实例。我向上推，检查，证书还在，坐在 Github 上。

有点奇怪的是，BFG 说有更多的内容需要清理——可能你的凭据在你认为的更多地方——但无论如何，不​​管是什么原因让你在第一次运行后看到它们仍然存在，是同样的原因你在第二次跑步后看到他们。

回去工作

在这一点上，我放弃并尝试重新开始工作，我想我稍后会解决它。

因此，此时您已经重写了 Git 存储库历史记录（两次！）并将其推送到 GitHub。但是您的帐户没有提到您删除所有本地旧副本，如 BFG 说明中所述：

“在这一点上，你已经准备好让每个人都放弃他们的旧版本的 repo 并重新克隆好的、新的原始数据。”

那么，您是否删除了工作机器上旧的 Git 存储库工作副本，并使用新的 Git 存储库历史重新克隆？您的旧仓库中的历史记录与当时存在于 GitHub 中的“已清理”历史记录不同（即使“已清理”历史记录不像您希望的那样“已清理”！）。

我做了一些工作，尝试向上推，得到一个奇怪的合并冲突（你在提交时领先 50 和落后 50）。

如果您在 Git 存储库的旧本地副本中进行工作（而不是从 GitHub 重新克隆），那么这就是您所看到的。您实际上是在向 GitHub 推送 50 个旧的、肮脏的历史提交，而对于 Git，您似乎很高兴地没有意识到该分支上已经有 50 个完全不同的提交（对于 Git，它只关心这里的提交 ID）。Git 认为您正在做的事情有点奇怪（“领先 50 和落后 50”）并试图告诉您。

让事情变得更糟...

什么？我尝试拉取和合并，突然间，我的 git 历史记录中的每一个提交都在名称上重复，其中一些只是空白。我检查了我的 Github 网络图，看起来从我的初始提交开始有第二个分支，它完全反映了我上次提交时压缩的所有提交

因此，通过拉取和合并，您已经将清理过的历史记录和肮脏的历史记录连接在一起，并通过合并提交将它们统一起来。在整理你的历史方面，这是一个坏主意。一个更好的主意是在清理过的历史的基础上重新构建你的新工作，推送它，删除你的旧工作存储库，然后进行新的克隆。

善后

当我现在尝试从头开始运行 BFG，重新克隆和镜像 repo 时，它告诉我其中没有凭据，尽管我可以在 Github 中看到它们。

这很奇怪，但是除了上面已经给出的“GitHub gc”解释之外，除了操作员错误之外，我真的没有任何解释。您可以与我共享存储库（如果您愿意），以便我可以执行更详细的检查，或者只是向我发送“.bfg-report”目录的压缩副本，以便我可以查看 BFG 在执行时捕获的诊断信息。

恢复

我真的可以使用一些帮助来理解发生了什么，以及如何（如果有的话）再次回到原来的状态。

我希望我已经设法解释了发生的一些事情。

在整理您的历史记录（即摆脱这两个重复的链）方面，您需要在添加该合并提交之前将您的 Git 历史记录重置回（清理）点。查看合并提交，并确定您喜欢哪个父历史记录。xxxx在您进行合并之前，该历史记录中的最后一次提交 ( ) 是什么？

git reset --hard master xxxx

这很可能会失去你对旧的、肮脏的历史所做的最后一点工作。yyyy识别那个提交（

git cherry-pick yyyy

最后，使用 'force' 标志将恢复的历史记录推送到 GitHub：

git push origin master -f

...压缩您的旧仓库的存档，然后删除您的仓库的所有旧本地副本，以防止您进一步混淆。做一个新鲜的克隆。

于 2014-07-03T23:37:59.677 回答