如何从 Github 中删除用户敏感数据

Question

我正在撰写 Github 文章“从存储库中删除敏感数据” ，以便从 Github 存储库中删除一些敏感数据，但我不知道如何“强制推送”我在本地完成的所有更改到 Github，让我更好地解释一下：

1. 我创建了一个测试fake_sensitive_data.txt并提交了一些虚假的敏感数据，一个名为fake_sensitive_data.txt的文件位于项目的根目录中。
2. 我开始向 repo 提交更多文件
3. 我创建了一个提交以从 repo 中删除敏感数据
4. 我将项目克隆到了不同的文件夹中
5. 在新的克隆文件夹，我删除fake_sensitive_data.txt从混帐历史使用命令bfg --delete-files fake_sensitive_data.txt ：

Using repo : git-test-removing-sensitive-data-clean/.git

Found 7 objects to protect
Found 3 tag-pointing refs : refs/tags/v1, refs/tags/v2, refs/tags/v3
Found 5 commit-pointing refs : HEAD, refs/heads/master, refs/remotes/origin/HEAD, ...

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

* commit b8c88b09 (protected by 'HEAD')

Cleaning
--------

Found 11 commits
Cleaning commits:       100% (11/11)
Cleaning commits completed in 73 ms.

Updating 6 Refs
---------------

       Ref                                       Before     After   
       -------------------------------------------------------------
       refs/heads/master                       | b8c88b09 | 82104232
       refs/remotes/origin/lev/pr-to-stay-open | 2b131b17 | 0bcfb420
       refs/remotes/origin/master              | b8c88b09 | 82104232
       refs/tags/v1                            | c740754e | b8a33de1
       refs/tags/v2                            | 4abc08c8 | a0fdb11d
       refs/tags/v3                            | a448a05e | 4c4176a7

Updating references:    100% (6/6)
...Ref update completed in 18 ms.

Commit Tree-Dirt History
------------------------

       Earliest      Latest
       |                  |
       . D D D DD D D D m m

       D = dirty commits (file tree fixed)
       m = modified commits (commit message or parents changed)
       . = clean commits (no changes to file tree)

                               Before     After   
       -------------------------------------------
       First modified commit | 0cd750f6 | dedd68e8
       Last dirty commit     | 2b131b17 | 0bcfb420

Deleted files
-------------

       Filename                  Git id          
       ------------------------------------------
       fake_sensitive_data.txt | cc86c97f (199 B)


In total, 18 object ids were changed. Full details are logged here:

       git-test-removing-sensitive-data-clean.bfg-report/2020-01-24/09-22-19

BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive

6. 清理完成后，我使用以下命令强制将内容推送到 Github： git push origin --force --all && git push origin --force --tags

所以这些是我为了从我的 repo 中清除文件fake_sensitive_data.txt遵循的步骤，现在我面临的问题：

1. 该文件仍保留在ACTIVE分支中。
2. 该文件仍保留在来自已删除且从未合并的分支的COMMITS 中。
3. 该文件仍保留在已合并到 master 的PR中。

所以我的问题是，如何从所有分支、提交、PR、标签（任何东西）中删除文件和历史记录并将其推送到 Github？

Answer 1

TL; 博士

你必须让 GitHub 做你需要的事情。 即便如此，如果提交已被复制到其他地方的其他存储库，那么您必须让所有其他副本（以及拥有它们的人）也更新他们的副本。

长

没有任何东西——地球上没有任何力量——可以从包含该文件的提交中实际删除该文件。 没有什么可以改变任何现有的提交，永远。 一旦提交，它实际上是一成不变的，或者一直冻结。

BFG 和git filter-branch所做的是通过将具有文件的提交复制到没有文件的新提交来进行新的和改进的提交。 （在这种情况下，新提交没有文件的事实是改进。）

到目前为止，这很简单。 旧的提交仍然存在，现在新的提交也在那里。 但是你想让旧的消失。 这就是一切都出错的地方。 这也是事情变得有点复杂的地方。

此时你应该问的问题是：

• Git 如何首先找到提交？
• 就此而言，任何人如何找到提交？ 提交的真实名称是什么？

上面有四个链接，其中一个是https://github.com/luivilella/git-test-removing-sensitive-data/tree/124e5707bf29a24cfb4167c869250fd919c42446 。 我将在此处显示完整的 URL。 请注意末尾很长的随机十六进制数字字符串124e5707bf29a24cfb4167c869250fd919c42446 。 这是提交的哈希 ID 。 它

这是提交的真实名称。 这就是拥有提交的人每次都能可靠地找到它的方式。 您只需要记住124eblahblah （硬）或将其写在某处，然后将其剪切并粘贴（简单）并运行git checkout hash-id即可完成并准备好使用。

现在，每个存储库——包括某个原始存储库的每个克隆——都包含它曾经获取的每个提交，减去它被抛出的任何提交。 请注意，BFG 的会议结束时建议运行：

 git reflog expire --expire=now --all && git gc --prune=now --aggressive

git gc命令是 Git 的死神垃圾收集器。 它是内务管理程序，或者更准确地说，是个人内务管理程序的主管，这些程序四处寻找提交和其他任何人都找不到的Git 对象。 如果你找不到对象——如果它的哈希 ID 没有写在 Git 可以看到的任何地方——那么，你显然不关心 Grim Collector 是否完全擦除它。

所以现在我们要问：

• 在哪里可以写下这些哈希 ID 以便 Git 可以看到它们？

对于 Git 本身，答案主要是：在其他提交中。 每个提交都可以列出一些其他提交的哈希 ID。 如果带有散列H的提交列出了提交散列 ID G ，那么任何可以找到H 的人都可以使用它来查找G 。 如果哈希 ID 为G的提交列出了提交F的哈希 ID，那么任何拥有H或G 的人都可以找到F 。

如果您想绘制它，请绘制一个带有一些箭头的提交。 这些是提交中的父提交哈希 ID 。 大多数提交只有一个。 合并提交有两个，分别是它们的两个父项。 ¹这些箭头总是向后指向以前的某个提交。 所以如果你能找到最后一次提交，你就可以找到每一次提交。

这就是分支名称 ( master )、标签名称 ( v1.2 ) 和远程跟踪名称 ( origin/master ) 之类的地方。Git 为您提供这些命名设备来查找特定的提交。 ²有了分支名称，这是我们应该说是分支的一部分的最后一次提交。 对于任何其他名称，这只是一些哈希 ID，例如，标签可以将特定提交标记为“使用此提交访问 1.2 版”。

这些名称统称为refs或references 。 当 BFG 说：

更新 6 条参考文献

这就是它所说的。 BFG将一些特定的原始提交复制到新的和改进的提交中。 然后，在复制了这些之后，它也必须复制所有后续提交，或者也改进它们（因为它们有你想要的文件），或者只是因为旧提交持有其他一些旧的和错误的提交的哈希 ID现在已经改进。

一旦 BFG 复制并改进了所有必须改进的内容，并复制了由于复制和改进而必须复制的所有其他内容，BFG 就会进入并适当地更改每个ref 。

但是 BFG 只能更改您存储库中的引用。 每个存在的 Git 存储库都有自己的引用。 所有 Git共享提交（通过复制），但它们不一定共享所有引用。

已经更新了自己的仓库的裁判，将高炉煤气现在建议您清除您的Git的reflogs，持有什么样的裁判散列的ID是日志（当然GIT中可以看到所有这些，所以那些保留旧提交居住）。 那是git reflog expire命令。 --expire=now部分表示不要将条目保留 30 或 90 天：现在将它们全部删除。 然后，BFG 建议您运行housekeeping git gc程序。 --prune=now删除了 Git 使用的标准 14 天宽限期，以便后台git gc操作不会删除其他一些 Git 命令正在制作的对象。 ³

因此，在此步骤之后，您的存储库不再有“坏”提交。 如果您尝试git checkout hash ，您的 Git 会说：我的对象数据库中似乎没有那个哈希 ID。 它消失了！ 一切安好。

但那是您的Git 存储库。 所以现在你使用git push origin --force ：这让你的 Git 调用另一个 Git——在 GitHub 上的那个——并给他们任何他们需要的新对象（提交和内部对象），例如新的和改进的对象BFG 制造的。 然后你的 Git 发送强有力的命令：对于分支名称master ，设置该分支名称以记住提交 X！ 对于标签名称v1.2 ，设置标签名称以记住提交Q ！ 等等。

如果他们服从（如果你有正确的权限，他们会这样做），现在 GitHub 的 Git 只能通过这些名称找到那些提交。 这些提交可以找到较早的提交，依此类推。 但是GitHub 的 Git并没有删除其他提交。 当他们的Git 开始运行git gc时，他们会这样做。 此外，他们可能有他们从未告诉过您的参考名称。

你在这里提到的是拉取请求。 GitHub 通过设置特殊的 GitHub 专用名称refs/pull/*实现拉取请求。 根据使 GitHub 正常工作的所有规则，他们会在适当的时候将这些名称复制到其他 GitHub 端存储库中。 但是它们不允许您设置或删除它们。 另请参阅从 GitHub 删除已关闭的拉取请求。

所以：您必须联系 GitHub 支持并让他们删除任何使“坏”提交保持活动状态的 PR。 你也必须让他们强制他们的 Git 运行适当的git gc以在默认维护窗口过去之前放弃提交。 只有这样，引用这些 PR 或通过哈希 ID 提交的 URL 才会停止工作。 当然，您必须记住，任何可以克隆或访问您的 GitHub 存储库的人现在可能已经将这些提交复制到他们自己的存储库中，并且可能拥有您的数据：让他们放弃它的唯一方法是去他们，无论他们是谁。

---

¹一些合并提交，Git 称之为octopus merges ，可以有两个以上的父项。 箭头仍然必须指向后方。

²标签名称可以直接指向其他 Git 内部对象，例如tree或blob 。 树是 Git 存储提交文件名称的方式，而Blob是 Git 存储文件内容的方式——每个文件的数据。 标签名称还可以指向 Git 的最后一个内部对象类型，即带注释的标签对象。 带注释的标签对象包含一些先前存在的对象的哈希 ID，当然还有注释。

³当 Git 构建新的提交或其他数据时，这个宽限期大大简化了它的构建方式。 Git 可以左右创建对象，获取目前只有一个程序拥有的新哈希 ID：没有保存在任何地方，也找不到这些对象。 然后，最后，当一切准备就绪时，对象创建者将最重要的哈希 ID（例如，用于分支中最后一次提交的哈希 ID）写入某个 ref。 现在对象都可以找到了，过程就完成了。

如果出现问题——例如，Git 发现由于某种原因无法进行某些提交——对象——创建程序可以简单地立即退出。 它创建的任何未使用的对象将在宽限期内闲置，然后git gc的下一次运行，无论何时——Git 会自动为你运行它，这样你就不需要考虑它——将找到并删除剩下的垃圾。