前面发过一个帖子，git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的，引发了激烈讨论。
然而，故事还没完。
场景是，我们有上亿的 git 仓库，大几百 T ，分布在几十块云盘，这些仓库之间存在深层次的 fork 关系，上亿的仓库可能母仓库就几万个。 那么 fork 关系与其底层的磁盘存储的关系如下： A(位于磁盘 1) -> B(位于磁盘 1) -> C(位于磁盘 2) -> D(位于磁盘 3) -> E(位于磁盘 1) -> F(位于磁盘 2) 假定仓库 A 的大小是 200M ，由于 git 服务端的 alternates 机制存在，同一块磁盘会通过硬链接节约磁盘空间，整体这 6 个仓库在几块盘上的占用空间只有 600M ，而不是 200*6=1200M
现在的问题是我想做冷热仓库的分离，对于上亿的 git 仓库可能就几百万的活跃，但是如果按照时间一刀切，把不活跃的仓库迁移到 oss ，比如把 oss 挂在到云主机通过 rsync 拷贝或者通过 oss api 上传，都会导致这里的 A 、B 、E 三个库就变成了 600M ，一个库还好，大量的这种仓库的存在会导致冷存储的存储量的爆炸式增长
各位有什么建议的方案么？
 |
1
dajj 1 天前  2
你们把 github 爬了？
|
 |
2
stinkytofux 1 天前
给不了建议, 能玩这个量级的人才估计不多.
|
 |
3
TrembleBeforeMe 23 小时 56 分钟前
Package managers keep using git as a database, it never works out | Andrew Nesbitt
https://nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html Using git as a database is a seductive idea. You get version history for free. Pull requests give you a review workflow. It’s distributed by design. GitHub will host it for free. Everyone already knows how to use it. Package managers keep falling for this. And it keeps not working out. |
 |
4
SURA907 23 小时 44 分钟前
gitcode ？爬的真不少啊
|
 |
5
opengps 23 小时 19 分钟前
不给建议，这么大型的项目又不给钱
|
 |
6
snylonue 22 小时 23 分钟前
fork 不就是 branch 吗，其实是一个仓库
|
 |
7
laminux29 21 小时 59 分钟前
思路错了，不应该按仓库进行冷热分离，而是应该按文件使用频率来进行冷热分离。这样方案就很好找了。
|
Select Language