继承的bitbucket repo非常大：如何删除一些旧的提交？

Question

我继承了 Bitbucket 存储库中的一个项目，大小为 3.7 GB。这是包含一些与我的问题相关的信息的结构：

作者	承诺	留言	日期
我	F	标签v2.1.0	今天
...	E	...	...
上一页	D	标签v1.0.0	前段时间
...	C	...	...
...	B	...	...
...	A	...	...

考虑到我已接近 4GB 硬限制，我想知道是否有办法删除除 D 和 F 之外的所有提交。这样，我们的客户端将拥有两个可用的功能版本，并且我们将释放占用空间但未使用的提交存储库。

我正在考虑这样做，但我经验很少：

1. 将存储库 (v1.0.0) 的 D 提交拉到新的本地文件夹，与 2.1.0 所在的位置分开。
2. 使用 rebase（不是这方面的专家）从这个新的本地文件夹推送。这应该使用当前提交“重新设置”远程存储库，删除其他所有内容（对吗？）。我想使用标签 1.0.0 来保留现有版本的命名。
3. 从本地 2.1.0 目录中获取这个新的重新基址远程存储库。
4. 通过仅保留本地 (2.1.0) 文件夹中的内容并忽略来自远程文件夹 (1.0.0) 的内容来合并新更改。 我该怎么做？
5. 使用

   --force-upstream

   标志从新合并的主本地文件夹（其中 2.1.0 所在）推送。这应该只会留下 1.0.0 和 2.1.0 标记版本

希望你能帮助我！有人可以通过这个看似非常容易出错的过程提供指导吗？我害怕在这个过程中丢失东西......

Answer 1

删除提交可能不会像您预期的那样显着减少存储库大小。你可以尝试一下，看看它能变小多少。

# create an orphan branch foo from D
git checkout --orphan foo D
git commit -m'commit message'

# create a new commit that tracks the same files with F
git merge $(git commit-tree -p HEAD -m 'commit message' F^{tree})

# create a bundle of foo and check its size
git bundle create foo.bundle foo
du -h foo.bundle

如果新存储库只有

foo

作为初始分支，则可以将

foo.bundle

的大小视为新存储库的初始大小。将其与旧存储库的大小进行比较

.git

（由

du -sh .git

），您将得到一个粗略的估计，它会变小多少。

在某些情况下，新尺寸可能几乎相同。举个例子，从

A

到

F

只添加新文件，不修改或删除任何文件。

3.7 GB 相当大，强烈建议使用

git lfs

来管理二进制文件。否则，在跟踪新的二进制文件后，新的存储库将再次变得巨大。