Lui*_*lla 4 git version-control github
我正在阅读 Github 文章“从存储库中删除敏感数据”，以便从 Github 存储库中删除一些敏感数据，但我不知道如何“强制推送”我在本地对 Github 所做的所有更改，让我更好地解释一下：
fake_sensitive_data.txt位于项目根目录中。fake_sensitive_data.txt使用以下命令从 git 历史记录中删除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
git push origin --force --all && git push origin --force --tags因此，这些是我为了fake_sensitive_data.txt从我的存储库中删除该文件而遵循的步骤，现在我面临的问题是：
所以我的问题是，如何从所有分支、提交、PR、标签（任何内容）中删除文件和历史记录并将其推送到 Github？
您必须让 GitHub 来做您需要的事情。即使这样，如果提交已被复制到其他地方的其他存储库，您也必须让所有其他副本（以及拥有它们的人）也更新他们的副本。
\n\n没有什么\xe2\x80\x94地球上没有电源\xe2\x80\x94实际上可以从包含该文件的提交中删除该文件。任何现有的提交都无法改变。一旦提交完成，它实际上就被固定下来，或者永远冻结。
\n\nBFG 所做的git filter-branch就是通过将包含该文件的提交复制到不包含该文件的新提交来进行新的和改进的提交。（在这种情况下，新提交没有该文件这一事实就是改进。）
到目前为止，这非常简单。旧的提交仍然存在，现在新的提交也在那里。但你希望旧的消失。这就是一切出错的地方。这也是事情变得有点复杂的地方。
\n\n此时您应该问的问题是：
\n\n上面有四个链接，其中之一是https://github.com/luivilella/git-test-removing-sensitive-data/tree/124e5707bf29a24cfb4167c869250fd919c42446。我将在此处显示完整的 URL。请注意末尾有一串看起来很随机的十六进制数字124e5707bf29a24cfb4167c869250fd919c42446。这是提交的哈希 ID。它
这是提交的真实名称。 这就是拥有提交的人每次都能可靠地找到它的方式。您只需记住124eblahblah（困难）或将其写在某处，然后剪切并粘贴（简单）并运行，您就可以将其取出并准备使用。git checkout hash-id
现在，每个存储库\xe2\x80\x94（包括某些原始存储库\xe2\x80\x94 的每个克隆）都包含它所拾取的每个提交，减去它抛出的任何提交。请注意，BFG 在结束会议时建议运行：
\n\n\n\n\nRun Code Online (Sandbox Code Playgroud)\ngit reflog expire --expire=now --all && git gc --prune=now --aggressive\n
该git gc命令是 Git 的Grim Reaper垃圾收集器。它是内务管理程序，或者更准确地说，是各个内务管理程序的主管，负责四处寻找提交和其他无人能找到的 Git 对象。如果你找不到对象\xe2\x80\x94，如果它的哈希ID没有写在Git可以看到的任何地方\xe2\x80\x94，那么，你显然不关心Grim收集器是否删除完全是这样。
所以现在我们要问：
\n\n对于Git本身来说，答案主要是：在其他提交中。每个提交都可以列出一些其他提交的哈希 ID。如果具有哈希H 的提交列出了提交哈希 ID G，则任何可以找到H 的人都可以使用它来查找G。如果哈希 ID 为G的提交列出了提交F的哈希 ID ，则具有H或G的任何人都可以找到F。
\n\n如果你想绘制它，请绘制一个带有一定数量的箭头的提交。这些是提交中的父提交哈希 ID 。大多数提交都只有一个。合并提交有两个，对于它们的两个父母。1 这些箭头始终向后指向某个先前的提交。因此，如果您可以找到最后一次提交，那么您就可以找到每个提交。
\n\n这就是分支名称 ( master)、标签名称 ( v1.2) 和远程跟踪名称 ( origin/master) 之类的东西的用武之地。Git 为您提供了这些命名设备来查找一个特定的提交。2 使用分支名称，这就是我们应该说是分支一部分的最后一次提交。对于任何其他名称，这只是一些哈希 ID，例如，标签可以将特定提交标记为“使用此提交访问版本 1.2”。
这些名称统称为refs或references。当 BFG 说：
\n\n\n\n\n更新 6 条参考文献
\n
这就是它所说的。BFG将一些特定的原始提交复制到新的和改进的提交中。然后，在复制这些内容后，它还必须复制所有后续提交，要么也改进它们（因为它们具有您想要消失的文件），要么只是因为旧提交保存了其他一些旧的和坏的提交的哈希 ID现在已经得到改善。
\n\n一旦 BFG 复制并改进了所有需要改进的内容，并复制了由于复制和改进而必须复制的所有其他内容，BFG 就会介入并适当地更改每个引用。
\n\n但 BFG 只能更改您存储库中的引用。 每个存在的 Git 存储库都有自己的引用。 所有 Git 都共享提交（通过复制），但它们不一定共享所有引用。
\n\n更新了您自己的存储库的引用后，BFG 现在建议您清除 Git 的reflogs，其中保存了引用哈希 ID 的日志（当然 Git 可以看到所有这些，因此它们保留旧的现场提交）。这就是命令git reflog expire。该--expire=now部分表示不要将条目保留 30 或 90 天：立即将其全部删除。 然后，BFG 建议您运行内务管理git gc程序。删除--prune=now了 Git 使用的标准 14 天宽限期，以便后台git gc操作不会删除其他某个 Git 命令正在创建的对象。3
因此，在此步骤之后，您的存储库不再有“错误”提交。如果您尝试这样做，您的 Git 会说：我的对象数据库中似乎没有该哈希 ID。 它消失了！一切安好。git checkout hash
但这是你的Git 存储库。所以现在你使用git push origin --force：这让你的 Git 调用另一个 Git\xe2\x80\x94（位于 GitHub\xe2\x80\x94 的 Git\xe2\x80\x94），并为他们提供他们需要的任何新对象（提交和内部对象），例如新的以及 BFG 制作的改进版。然后你的 Git 发送强制命令：对于分支名称master，设置该分支名称以记住提交 X！对于标签名称v1.2，设置该标签名称以记住提交Q！等等。
如果他们服从（如果你有正确的权限，他们就会这样做），现在 GitHub 的 Git 只能通过这些名称找到那些提交。这些提交可以找到更早的提交，等等。 但GitHub 的 Git尚未 删除其他提交。当他们的Git 开始运行时git gc，无论什么时候，他们都会这样做。此外，他们可能有从未告诉过你的参考名称。
您在这里提到的那些是拉取请求。GitHub 通过设置特殊的 GitHub 专有名称refs/pull/*. 他们根据 GitHub 运行的所有规则，在适当的时候将这些名称复制到其他 GitHub 端存储库中。但他们不允许您设置或删除它们。另请参阅从 GitHub 删除已关闭的拉取请求。
因此：您必须联系 GitHub 支持并让他们删除任何使“不良”提交保持活动状态的 PR。git gc您还必须让他们强制 Git 在默认维护窗口过去之前运行适当的操作来丢弃提交。只有这样，引用这些 PR 或通过哈希 ID 提交的 URL 才会停止工作。当然，您必须记住，任何可以克隆或访问您的 GitHub 存储库的人现在都可能已将这些提交复制到他们自己的存储库中，并且可能拥有您的数据：让他们放弃的唯一方法是转到他们，无论他们是谁。
1一些合并提交（Git 将其称为octopus merges）可以有两个以上的父级。箭头仍然必然指向后方。
\n\n2标签名称可以直接指向其他 Git 内部对象，例如树或blob。树是 Git 存储提交时的文件名称的方式，而blob是 Git 存储文件内容\xe2\x80\x94（每个文件的数据）的方式。标签名称还可以指向 Git 内部对象类型的最后一个，即带注释的标签对象。带注释的标签对象包含一些先前存在的对象的哈希 ID，当然还有注释。
\n\n3当 Git 构建新的提交或其他数据时，此宽限期大大简化了其执行方式。Git 可以左右创建对象，获取当前只有一个程序拥有的新哈希 ID：没有任何内容保存在任何地方，也找不到这些对象。然后，最后，当一切准备就绪时，对象创建者将最重要的哈希 ID\xe2\x80\x94（分支中最后一次提交的哈希 ID，例如 \xe2\x80\x94）写入某个引用。现在所有对象都可以找到，并且该过程已完成。
\n\n如果出现问题\xe2\x80\x94Git 发现某些提交由于某种原因无法进行，例如\xe2\x80\x94 对象——创建程序可以立即退出。它创建的任何未使用的对象都将在宽限期内保留下来，然后下一次运行时git gc，无论何时 \xe2\x80\x94Git 都会自动为您运行它，以便您无需考虑它\xe2 \x80\x94 将找到并删除剩余的垃圾。
| 归档时间： |
|
| 查看次数： |
1868 次 |
| 最近记录： |