在git rebase中删除提交-i不会减少.git文件夹的大小

我有一个git存储库，

.git

文件夹是7MB。然后，我添加并提交了一个.exe文件，该文件为16MB，后跟：

git gc --aggressive && git prune

在上面的

.git

之后，我的文件夹现在是23MB

接下来，我做了一个

git-rebase-I

并选择了drop：

在引入16MB文件的提交（c8185ff）中，我完成了重基并再次运行：

git gc --aggressive && git prune

现在，当我测量

.git

文件夹时，它仍然23MB

上面执行的

git-rebase

是否应该从历史记录中完全删除提交文件（就好像从未引入该文件一样），从而将

.git

文件夹恢复为7MB大小

---

我还尝试对存储库进行新的克隆，但大小仍然是23MB——我假设在进行新的克隆时会清除reflog。

默认情况下，

git gc

只修剪松散的超过2周的对象

要对所有对象强制修剪，请使用：

但是，如果对象仍然可以通过任何引用（例如

origin/master

或reflog等远程引用）访问，则不会对其进行修剪

这就是为什么我们现在还必须将配置设置为

---

（对于

git prune

[在gc之后没有必要]，它是）

我怀疑从reflog仍然可以访问commit。在c8185ff中引入了大的.exe文件，它以前不存在。我删除了我的答案，在做了一个测试后，我看到rebase重写了树并证明了我的理论不正确。你不能把生成这个exe的代码放进去吗，而不是直接添加到git？我认为将二进制文件放在存储库中不是一个好主意……我完全同意不应该提交二进制文件，但这篇文章纯粹是为了理解在git中重写历史是如何与git rebase一起工作的——例如，事故发生的时间。当我在原始存储库上执行上述操作时，git仍然是23MB。如果我把它克隆到一个新的位置。git文件夹仍然是23MB，但是如果我运行'git-gc--prune=all'，那么它就会降到原来的7MB。还尝试在原始存储库上使用“git prune--expire now”（git prune--expire now），但似乎我需要在新的克隆上执行此操作，以查看效果/验证它是否不再存在于历史记录中。我修复了我的答案，同时清除了reflog。

git -c gc.reflogExpire=now gc --prune=all