my-git

Uber GitFarm 与 Git 服务化实践

原文链接：

1. 为什么 Git 会变成基础设施问题

在超大 monorepo 里，Git 的成本不只发生在开发者本机。

大量自动化系统也会 clone、fetch、checkout、sync：

当这些系统都各自维护本地 Git 副本时，冷启动和同步成本会成为基础设施瓶颈。

2. GitFarm 的核心思路

GitFarm 把 Git 操作抽象成远程服务，让自动化系统按需请求仓库状态和 checkout 结果，减少每台机器都完整 clone 的成本。

它的启发是：当仓库大到一定程度，Git 不再只是开发者工具，也会成为平台团队要运营的基础服务。

3. 对普通团队有什么启发

大多数团队不需要自己做 GitFarm，但可以提前观察这些信号：

出现这些信号时，先不要急着拆仓库，可以按顺序优化：

  1. CI 使用 shallow clone 或 partial clone
  2. 开发者使用 partial clone + sparse checkout
  3. 大仓库开启 git maintenance
  4. 构建系统按路径判断影响范围
  5. 高频自动化任务使用缓存或共享对象池
  6. 再评估是否需要更深的平台化方案

4. 对 Monorepo 决策的提醒

Monorepo 的收益是依赖统一、跨服务变更容易、代码搜索和治理集中。

成本是工具链复杂度上升。

团队做 monorepo 决策时，要同时评估：

只讨论“一个仓库还是多个仓库”是不够的。

5. 对本仓库的启发

大仓库实践要写成一组渐进策略：

clone 优化
-> 工作区裁剪
-> 本地维护
-> CI 缓存
-> 路径影响分析
-> Git 服务化

这样读者可以按团队规模逐步采用，避免一上来照搬超大公司方案。

This site is open source. Improve this page.