GitHub 10倍提交量压垮服务器，有人把仓库搬进谷歌硬盘了

GitHub 最近的服务稳定性问题，已经让一部分开发者开始寻找替代方案。不是迁移到 GitLab 或 Bitbucket，而是直接把私有仓库搬进了自己的谷歌硬盘。

这个方案听起来像技术宅的恶作剧，但背后有一套完整的工程逻辑。它不需要额外服务器，不需要学习新命令，推送速度比远程仓库快一个数量级。

为什么云存储能当 Git 服务器用

Git 的设计本身就支持这种玩法。每次你执行 git push，本质上是在把本地仓库的变更同步到一个"远程"位置。这个远程可以是 GitHub 的服务器，也可以是你硬盘上的另一个文件夹。

谷歌硬盘、OneDrive、iCloud、Dropbox 这些云存储的桌面客户端，做的事情和 Git 的远程机制完美契合：监控文件变更、增量同步、保持多端一致。当你把仓库设为"裸仓库"（bare repository）——只存版本历史、不含工作文件——它就变成了一个合法的 Git 远程端点。

裸仓库的关键在于你永远不会直接修改它。所有操作都通过本地工作区发起，云存储只负责被动接收和同步。这避免了多人同时编辑引发的冲突，也让你的现有项目结构完全不受影响。

但这里有个陷阱：默认配置下的 Git 仓库会让云存储客户端崩溃。

数万个小文件是云存储的噩梦

Git 把每次提交的每个文件版本都存为独立对象。一个中型项目的 .git/objects 目录里，轻松躺着几万个几十字节的小文件。

云存储的同步引擎是为大文件优化的。Dropbox 和谷歌硬盘擅长处理"这个 50MB 的 PSD 改了"，而不是"这 3 万个 100 字节的对象有 47 个变了"。直接同步裸仓库，你会遇到文件锁竞争、同步死锁、甚至数据损坏。

解决方案是强制 Git 使用"包文件"（packfile）。包文件把分散的对象打包成单个高度压缩的二进制文件，通常能减少 70% 以上的存储体积，同时把同步单元从"万个文件"变成"几个文件"。

具体操作需要四行配置：

git config gc.auto 0 —— 关闭自动垃圾回收，防止后台任务移动文件
git config core.filemode false —— 忽略文件权限差异
git config repack.writeBitmaps true —— 加速大仓库的克隆速度
git config cloud.pack true —— 自定义标记，方便后续自动化脚本识别

最后一步：右键仓库文件夹，选择"始终保留在此设备"。云存储的"文件按需下载"功能会把旧版本标记为离线，导致 Git 读取时抛出"bad object"错误。强制本地保留能彻底规避这个问题。

实测：本地 SSD 到云盘的推送速度

配置完成后，添加远程仓库的命令和平时没什么两样：

git remote add gdrive "G:\My Drive\Backups\project.git"

第一次推送用 git push gdrive --all 同步所有分支。之后的日常操作完全透明——git push gdrive main 和推送到 GitHub 没有区别，只是数据流向从"本机 → 互联网 → GitHub 服务器"变成了"本机 SSD → 本机 SSD 的另一个文件夹 → 云存储后台同步"。

推送延迟从几百毫秒降到几毫秒。对于频繁提交的开发节奏，这种体感差异很实在。

这个方案的隐性成本在于你失去了 GitHub 的协作基础设施。没有 Pull Request、没有 Issue 追踪、没有 Actions 流水线。它最适合的场景是：个人私有项目、需要离线可用的备份、或者对代码托管商周期性不信任时的保险副本。

一位在 Hacker News 讨论这个方案的开发者说，他已经用这种配置跑了两年，三个项目的仓库分布在谷歌硬盘和 iCloud 之间，"从没丢过数据，也没付过 GitHub 的私有仓库费用"。

当 GitHub 的可靠性成为需要被对冲的风险，把仓库主权收回自己手里，是不是一种更务实的选择？