blocks|key|2031343|text|据我从输出中了解，该文件已从commit+9e96a248322ba6e85efde1e1498db0d41c1ee79中删除。|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2031344|git+filter-branch删除了该文件，创建了一个新的提交。新提交具有不同的哈希，因为其内容不同。在运行git+gc之前，使用散列9e96a248322ba6e85efde1e1498db0d41c1ee79的原始提交仍然存在。请注意，如果运行git+log+%7C+grep+9e96a，将不会出现该哈希，因为相应的提交已不在历史记录中。|unstyled|offset|length|style|CODE|BOLD|2031345|要更详细地理解这一点，我建议您阅读有关如何创建提交的文章。这篇博客文章解释得很好。Pro+Git中的这一章详细介绍了git的内部管道以及如何创建提交。|2031346|entityMap|0|LINK|mutability|MUTABLE|url|https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html|1|https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain^0|0|0|H|1K|6|3I|K|O|9|0|T|6|0|15|C|1|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|W|8|@$E|X|F|Y|G|H]|$E|Z|F|10|G|H]|$E|11|F|12|G|H]|$E|13|F|14|G|I]]|9|@]|A|$]]|$1|J|3|K|5|D|7|15|8|@]|9|@$E|16|F|17|1|18]|$E|19|F|1A|1|1B]]|A|$]]|$1|L|3|-4|5|D|7|1C|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

<blockquote>
 as I understand from the output the file was removed from commit 9e96a248322ba6e85efde1e41498db0d41c1ee79
</blockquote>

<code>git filter-branch</code> removed the file and created a new commit. The new commit has a different hash because its contents are different. The original commit with the hash 9e96a248322ba6e85efde1e41498db0d41c1ee79 still exists until you run <code>git gc</code>. Note that if you run <code>git log | grep 9e96a</code>, that hash will not appear because the corresponding commit is no longer in your history.

To understand this in more detail, I suggest you read about how a commit is created. <a href="https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html" rel="nofollow noreferrer">This blog article</a> explains it well. And <a href="https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain" rel="nofollow noreferrer">this chapter in Pro Git</a> goes into detail about the internal plumbing of git and how a commit is created.

blocks|key|2874520|text|代码学徒的回答基本上是正确的，但要详细说明一下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2874521|修改提交是不可能的。filter-branch+(或任何历史重写机制)所做的是创建新的提交，这些提交“就像”现有的提交，但需要进行所需的更改。(例如，您的新提交文件中没有大文件，但否则它们看起来就像您以前的提交)|offset|length|style|CODE|2874522|这有两个重要的后果。|2874523|首先，在重写分支的历史记录之后，任何拥有该分支副本的其他人都需要执行一些恢复步骤。您可以在git+rebase文档中了解这些内容(在“从上游重基恢复”下)。如果他们做了错误的事情来恢复，它将撤消历史重写(将大文件放回历史中)，因此您需要每个人在重写历史时进行合作。因此，重写历史有时是不切实际的。对于大型重写(特别是影响复杂历史、多个分支等的重写)通常情况下，最好是安排一次剪裁，每个人都放弃他们现有的克隆，然后从重写的回购重新克隆。|2874524|(其中的一个细微之处是，当您重写历史记录时，依赖于提交ID的任何工具或文档也会被破坏。)|2874525|第二，这意味着执行重写不会立即从回购中删除旧的提交。如果您试图从二进制膨胀中恢复空间，以及试图清除回购历史中的敏感信息泄漏，这一点都很重要。(在后一种情况下，几乎总是有必要将信息视为已泄露的信息。)|2874526|运行git+gc可以是解决方案的一部分，但这还不够。这是因为在您完成重写之后，您的回购仍然有对旧提交的引用，因此gc不会将它们视为垃圾。至少，您需要清除重发；可能还有其他问题。|2874527|有一些方法可以做到这一点，但通常我通过从重写的回购中复制一个新的克隆来回避这个问题。那个克隆人不应该费心复制旧的/删除的历史。(要明确的是--我不认为有任何有记载的要求说这样的克隆不能复制已经失效的历史，但根据我的经验-至少在使用标准的git实现时-没有。)然后你可以摧毁原产回购和重建它从完全消毒的克隆。|2874528|entityMap^0|0|A|D|0|0|19|A|0|0|0|2|6|1K|2|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$D|11|E|12|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@$D|16|E|17|F|G]|$D|18|E|19|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|U|$]]

The answer by code-apprentice is mostly correct, but to elaborate a bit:

It is impossible to modify a commit. What <code>filter-branch</code> (or any history-rewriting mechanism) does is to create new commits that are "just like" existing commits, but with the changes you ask for. (e.g. your new commits don't have the large file in them, but otherwise they look like your old commits)

This has two important consequences.

First, after you rewrite the history of a branch, anyone else with a copy of that branch will need to perform some recovery steps. You can learn about those in the <code>git rebase</code> documentation (under "recovering from upstream rebase"). If they do the wrong thing to recover, it will undo the history rewrite (putting the large file back in the history), so you need everyone to cooperate when rewriting history. For that reason, sometimes it is not practical to rewrite history. For large rewrites (especially those affecting a complex history, multiple branches, etc.) it is often best to arrange a cut-over where everyone discards their existing clones and then re-clones from the rewritten repo.

(A nuance of that, is that any tooling or documentation that depends on commit IDs is also broken when you do a history rewrite.)

Second, it means that doing the rewrite does not immediately remove the old commits from the repo. That's important both if you're trying to recover space from binary bloat, and also if you're trying to clean up a leak of sensitive information into the repo history. (In the latter case, it's almost always necessary to treat the information as compromised.)

Running <code>git gc</code> can be part of the solution, but it isn't sufficient. That's because right after you do the rewrite, your repo still has references to the old commits, so <code>gc</code> doesn't see them as garbage. At a minimum, you'd need to cleanse the reflogs; there may be other issues as well.

There are ways to do that, but generally I sidestep the issue by just making a new clone from the rewritten repo. That clone shouldn't bother copying the old/removed history. (To be clear - I don't think there's any documented requirement that says such a clone can't copy the defunct history, but in my experience - at least when using the standard git implementation - it doesn't.) Then you could destroy the origin repo and recreate it from the fully-sanitized clone.

In one old commit a big file was added. After several commits it was removed however it stay in the history so I am trying to remove this file from history by the following command:

<code>git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch src/main/resources/embed/linux/mongodb-linux-x86_64-3.2.0.tgz" --pru-tag-name-filter cat -- --all</code>

the result of this command is following:

<pre><code>Rewrite 9e96a248322ba6e85efde1e41498db0d41c1ee79 (3026/5151) (13917 seconds passed, remaining 9773 predicted) rm 'src/main/resources/embed/lib-linux-x86_64-3.2.0.tgz'
Rewrite 070cbe84ad8e1bc8f1ccec5294b600218d714e30 (4123/5151) (18963 seconds passed, remaining 4728 predicted) rm 'src/main/resources/embed/lib-linux-x86_64-3.2.0.tgz'
Rewrite 1f5604b332d6d48169fa398b60fc5ac42124d63d (5151/5151) (24005 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/master' was rewritten
....
</code></pre>

as I understand from the output the file was removed from commit <code>9e96a248322ba6e85efde1e41498db0d41c1ee79</code>, so I check this:

<pre><code>git checkout 9e96a248322ba6e85efde1e41498db0d41c1ee79
ls src/main/resources/embed/linux/
</code></pre>

the result is <code>mongodb-linux-x86_64-3.2.0.tgz</code>. So the file still exist in the history. What I did wrong? How can I remove it compliantly?

Removed file from git history still exists?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在一次旧提交中，添加了一个大文件。在多次提交之后，它被删除了，但是它停留在历史记录中，因此我试图通过以下命令从历史记录中删除该文件：git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch src/main/resources/e...

问从git历史中删除的文件仍然存在吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问从git历史中删除的文件仍然存在吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问从git历史中删除的文件仍然存在吗？
EN