前面发过一个帖子，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 20 天前  6
你们把 github 爬了？
|
 |
2
stinkytofux 20 天前
给不了建议, 能玩这个量级的人才估计不多.
|
 |
3
TrembleBeforeMe 20 天前
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 20 天前
gitcode ？爬的真不少啊
|
 |
5
opengps 20 天前
不给建议，这么大型的项目又不给钱
|
 |
6
snylonue 20 天前
fork 不就是 branch 吗，其实是一个仓库
|
 |
7
laminux29 20 天前
思路错了，不应该按仓库进行冷热分离，而是应该按文件使用频率来进行冷热分离。这样方案就很好找了。
|
 |
8
TomVista 19 天前
拉个 pb 级的存储池单例就完事了
|
 |
9
yanguangs 19 天前
gitcode? 重庆开源?
|
 |
10
gz222 19 天前
问题不出在存储，而是一旦换了非 Git 自带的原生数据结构，你们公司有能力自己实现 git-log 、git-blame 这些操作吗？连 GitLab 都没做到这一步。
如果我来做，git 的 packed 数据完全打散成 loose ，这样大概会带来 20 倍的硬盘占用，不过所有的 git object 就可以处理之后去重丢数据库了。后面热点仓库、热点分支、热点对象再筛选一下拉到独立的节点构建 git-commit-graph 什么的。 |
 |
11
QS0x01 18 天前
不会是傻逼 csdn 在爬 GitHub 吧
|
 |
12
Gilfoyle26 18 天前
又打算抄 github ？真没意思
|
Select Language