git - 如何在没有冲突的情况下自动压缩 git 存储库历史记录以缩小它？

Question

我有一个存储库已经变得太大以至于无法使用。基本上我的存储库超过 2GB，克隆时间太长。我现在想缩小它，但仍然能够回到一些特定的旧版本......缩小将涉及重写历史，所以我对此没有意见。拥有克隆的人将不得不在新的 repo 克隆中的新分支之上 rebase/cherrypick/copyfiles。

• 我在这个存储库中有二进制文件，但我在那里需要它们(将其视为软件运行的必需资源)。所以我不能真正使用 filter-branch 或 BFG删除一些大的二进制文件，因为在恢复到过去的提交时我可能需要它们。
• 我不关心以前的旧分支/已经 merge 的分支(例如:功能分支)，但我关心一些特定的提交(例如过去发布分支的负责人)
• 由于我将修改(~很多~)非常旧的提交，我现在不知道如何正确解决 merge 冲突(基本的 rebase/cherrypick 可能发生)所以我正在寻找一个不会产生任何问题的解决方案冲突，或只产生可以自动解决的冲突。
• 我想保留所有当前分支，以便在克隆上进行工作的人可以对它们进行 rebase /复制更改。
• 我想在我的新提交之间有相关的历史记录，以匹配旧存储库中的历史记录(就好像提交被压缩了一样)。当前分支的历史将从这些旧的压缩提交之一开始。

我认为它是一堆不需要的旧存储库历史记录。就我的案例而言，我提出的可能流程(我错过了一些步骤，我仍然不确定这是否会按照我的想法进行)是:

• 克隆现有存储库的镜像。
• 从我想保留的旧提交创建孤立分支。这将创建无父压缩提交，其中包含所有需要的文件。
• 以某种方式链接它们以重新创建旧的 repo 历史 => 如何？ merge/ rebase /重置+提交孤儿？
• Cherrypick 每个当前分支的提交列表(使用间隔)，并将它们应用到最新的提交，该提交压缩了他们第一个不同提交的父级 => 如何自动找到将 cherry picked 提交间隔应用到哪个提交？这会在没有冲突的情况下工作吗？
• 将标签移至新树。删除以前的树。 git 垃圾收集。

这是否可行/可行且没有任何冲突？这在任何情况下都有效吗(git 提交树可能非常复杂)？有没有更好的安全自动压缩历史的解决方案？

在我看来，这种类型的维护任务对于长期运行的项目来说是会发生的，所以我假设其他大型项目已经使用了某种类型的解决方案。但我想可能有一个我不知道的 git init(或另一个命令)选项，可以从旧的 repo 为这个用例创建一个新的 repo？

更新:我在这里找到了解决方案的开始:https://wincent.com/wiki/Editing,_amending,_or_squashing_the_root_commit_in_a_Git_repository但是我想以全自动的方式(即没有冲突)在我的历史记录中多次执行此操作...

Answer 1

您可以只克隆存储库的一部分:

git clone --depth depth 

这称为浅克隆。

那是一个post on the Atlassian blog前一段时间提供了处理大型 repo 的其他策略。