【问题标题】:Completely remove (old) git commits from history从历史记录中完全删除(旧)git 提交
【发布时间】:2011-02-13 22:29:07
【问题描述】:

我正在使用 git 开始一个项目,我将在其中提交非常大的文件,但每周只提交几次。我尝试按原样使用 git,它似乎将整个文件存储在每个更改的提交中。这对这个项目不起作用,存储库会失控。所以,我想减小存储库的大小。

我的第一个想法是“简单地”删除所有超过两周的提交,或者只保留例如历史上的五次提交(这可能更好:))我已经在 The Git Community Book 中搜索并阅读了很多内容,我想我需要使用 git-rebasegit-filter-branch。问题是我似乎无法让它工作。

只是为了说明;我的历史 H 只有一个分支(主分支)

A --> B --> C --> D --> E

我想删除一些以前的提交以使我的历史看起来像

C --> D --> E

应该完全清除提交 A 和 B。我试过git-rebase,但它似乎将提交合并在一起,而不是实际删除旧的,也许我不完全理解变基是如何工作的。我的另一个想法是从 .git/objects 中删除所有内容,然后构建一个使用git-hash-object -wgit-mktreegit-commit-tree 的新提交,我还没有设法将这个“人工”树推送到服务器。

我不会与任何分支机构合作,因此无需考虑这些。

我想知道是否有人可以给我git-rebase 的具体用法,如果那是我应该使用的?或者其他一些技巧,我可以做的例子。

干杯!


编辑:

大文件不会一直都是同一个大文件,有些文件会被新文件替换。我希望这些被替换的文件从历史记录中完全清除

【问题讨论】:

  • 以后的提交(C 以后)是否仍然包含大文件,或者它们之前已经被删除(git rm)?
  • 你用merge这个词来描述git-rebase让我觉得你不太了解git-rebasegit-rebase 将移动提交并将它们应用到不同的头部,或者,如果您通过 -i,让您重写和“压缩”提交、更改顺序、执行命令、编辑提交消息等。不涉及合并。
  • git 是适合这项工作的工具吗?如果您只想保留最后几张快照,那么这不是重点吗?为什么不直接使用平面文件存储?

标签: git size history rebase


【解决方案1】:

这应该是一个简单的git rebase -i 你有

p A
s B
s C
p D
p E

然后将 A-C 的提交消息编辑为只是 C 的提交消息。

git-rebase 会将所有提交“压缩”成一个提交,其对象与提交 C 的对象相同。

注意:如果您愿意,可以使用git filter-branch 更改先前提交中的大文件以实际匹配新文件。但这是一个危险的操作,我不想在意外时给你一个糟糕的命令。

【讨论】:

  • 这不会让历史看起来像A -- C' -- D -- E,其中 C' 仍然包含文件吗?
  • 不,你从哪里知道的?基本上,一旦你压扁了其他两个,提交 A 变成 提交 C。不过,您可能需要使用git gc 来清除对象。
  • 是的,但是如果 A 和 B 变成 C 并且 A 包含我要删除的大文件 - C 不会包含 A 的文件吗?假设我在提交 C 中添加一个大文件并在提交 D 中删除它,将 C 挤入 B 是否会从历史记录中删除大文件?如果我有点困惑,我很抱歉,我的大脑混乱了 :) 非常感谢您抽出宝贵的时间。
  • 提交 A 和 B 消失。就这些。提交 C 不会改变。
  • 在收到反对票后回顾这一点 - 您可能需要为自己的本地副本修剪数据库以删除大 blob 以及远程副本,但推送不会推送大文件。
猜你喜欢
  • 2014-11-20
  • 2013-08-03
  • 2015-09-02
  • 2017-06-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-01-22
  • 1970-01-01
相关资源
最近更新 更多