通过 hash/id 删除单个 git reflog 条目
我将敏感数据提交到我的 main 分支上的单个文件中。我从来没有推过它。我可以使用 git reset HEAD^ 更改 HEAD 以指向先前的提交，但提交仍然如 git reflog 所示。
如何使用引用日志哈希/ID 来完全删除/删除该提交？
I committed sensitive data to a single file on my main branch. I never pushed it. I can change HEAD to point to the previous commit with git reset HEAD^, but the commit is still hanging around as git reflog shows.
How can I use the reflog hash/ID, to COMPLETELY remove/delete that commit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
要删除特定的反射式条目，您可以使用：
这是在此处记录。有关删除所有回流历史记录或比特定日期历史悠久的历史记录，请参见此问答。
请注意，这将删除Reflog条目仅。有关完全删除该提交的更多信息，请参见 Torek的答案。
To remove a specific reflog entry, you can use:
This is documented here. For removing all reflog history, or history older than a certain date, see this question and answer.
Note, this removes the reflog entry only. For more information about completely removing the commit, see torek's answer.
您不能。 1 没有git命令可以通过哈希ID或reflog条目删除提交。
您可以放心，如果您使用的话：
可以通过遍历
somebranch向后提交的提示可以达到任何一个折射 - 输入。 consits，git push不会 send 那些提交（不需要的提交）。它将仅发送由git rev-list womenbranch列出的提交，减去接收git在要推向的存储库中已经具有的任何提交。因此，您 you 仍然有提交的事实并不重要。您可以做的其他事情 - 对偏执狂的利用，有时我会算上自己的群体 - 包括：
克隆您的克隆。由此产生的克隆不会有提交，因此您现在可以在该克隆中安全地运行：
从您的新克隆的
onement/somebranch（从您的旧克隆的somebranch）将提交发送到您的github存储库，请通过github（假设您的最终目标存储库在GitHub上；适当使用其他名称和URL）。使用
git reflog expire -expire-unreachable = all 2 或
git reflog delete -rewrite-updatere-updateref删除特定的特定，或所有无法实现的内容，来自某些（指定）返回的条目，或使用- 所有，都是所有reflogs。但是请注意，这不会删除 commit 。删除了回流条目后，运行
git gc -prune =现在。 在运行时，请确保在存储库中没有其他活动。如果您在中包装了对象。 （但另请注意，。保存是您必须手动创建的东西，因此您可能没有保留文件）。要验证提交确实消失了，请使用
git show＆lt; hash-id＆gt;或git cat cat-file -t＆lt＆lt; hash-id＆gt; 对于每个哈希ID。请注意，您需要将哈希ID保存在某个地方，因为没有任何对它们的内在引用（这就是允许git gc删除它们的原因）。1 如果 - 这是一个强的情况，但在您的情况下可能会满足 - 该提交从未被包装，您可能是able to use
rm .git/objects/xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwhere thexxs are the hash ID, split up into first-two and remaining hexadecimal characters.那不是 git 命令，您必须非常小心这个；首先复制或以其他方式备份存储库是一个好主意。 reflog条目仍然存在：如果您尝试使用它们，它们将变得毫无用处，因为git将会出现错误。2 此
所有应该是逻辑上是现在，我相信现在有效，但这是文档。You can't.1 There is no Git command that removes commits by hash ID or reflog entry.
You can however rest assured that if you use:
and the set of commits reachable by traversing
somebranch's tip commit on backwards does not reach any of the reflog-entry-only commits,git pushwon't send those commits (the unwanted ones). It will send only the commits listed bygit rev-list somebranch, minus any commits that the receiving Git already has in the repository to which you're pushing. So the fact that you still have the commits is not important.The other things you can do—useful for the paranoid, a group in which I count myself sometimes—include:
Clone your clone. The resulting clone won't have the commits, so you can now safely run, in that clone:
to send the commits from your new clone's
origin/somebranch(cloned from your old clone'ssomebranch) to your GitHub repository over atgithub(assuming your final target repository here is on GitHub; use other names and URLs as appropriate).Use
git reflog expire --expire-unreachable=all2 orgit reflog delete --rewrite --updaterefto delete specific, or all unreachable, entries from some (specified) reflog or, with--all, all reflogs. Note, however, that this does not delete the commit.Once the reflog entries are deleted, run
git gc --prune=now. Be sure nothing else is active in the repository while this runs. If you have packed objects in a.keep-kept file, though, this won't get rid of them (but also note that.keepis something you would have had to manually create, so you probably do not have keep-files).To verify that the commits are really gone, use
git show <hash-id>orgit cat-file -t <hash-id>for each hash ID. Note that you will need to save the hash IDs somewhere, since there won't be any in-Git references to them (that's what allowsgit gcto remove them).1If—this is a strong-ish condition but it may be met in your case—the commit has never been packed, you may be able to use
rm .git/objects/xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwhere thexxs are the hash ID, split up into first-two and remaining hexadecimal characters. That's not a Git command and you have to be very careful with this; it's a good idea to copy or otherwise back up the repository first. The reflog entries will still exist: they'll just become useless in that Git will barf up an error if you try to use them.2This
allshould logically benow, and I believenowworks, but it's what's listed in the documentation.