迁移实践与效能优化指南)
1. 多仓库管理的痛点与单仓库优势第一次接触Git多仓库管理时我像大多数开发者一样为每个项目创建独立仓库。随着业务复杂度提升这种模式开始暴露出明显问题跨仓库修改需要频繁切换上下文依赖管理变成噩梦CI/CD流程复杂到令人抓狂。最典型的场景是当我们需要修改底层工具库时往往要同时在5-6个仓库中提交关联改动。单仓库Monorepo模式的核心价值在于统一版本控制和依赖管理。Google、Facebook等科技巨头早已采用这种架构其优势主要体现在原子提交一次提交可跨多个项目/模块统一的依赖版本避免依赖地狱全局的代码可见性方便代码重用和重构简化的CI/CD单个流水线覆盖所有项目2. 迁移前的准备工作2.1 仓库拓扑分析使用git submodule foreach命令遍历所有子模块生成依赖关系图。我曾在一个电商项目中通过这个命令发现前端项目竟然嵌套依赖了3层共12个子仓库这种深度嵌套正是需要重点优化的结构。2.2 代码标准化统一所有仓库的代码规范是关键前提。建议使用pre-commit钩子确保# 示例pre-commit配置 repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.0.1 hooks: - id: trailing-whitespace - id: end-of-file-fixer2.3 分支策略设计单仓库需要更严谨的分支策略。推荐采用main生产环境代码release/*版本发布分支feature/*功能开发分支通过git worktree实现并行开发3. 迁移实操步骤3.1 创建基础仓库结构mkdir monorepo cd monorepo git init mkdir -p {apps,libs,scripts,docs}3.2 迁移子仓库保留历史使用git filter-repo工具迁移并保留提交历史git clone --bare 旧仓库URL git filter-repo --to-subdirectory-filter libs/库名 git remote add origin 新仓库URL git push --all重要提示迁移前务必在旧仓库打tag备份我曾因未备份导致历史提交丢失花了整周时间恢复3.3 依赖关系重构将package.json中的相对路径依赖改为workspace协议{ dependencies: { shared/utils: workspace:* } }4. 单仓库管理进阶技巧4.1 使用Lerna管理多包npx lerna init # lerna.json配置示例 { packages: [libs/*], version: independent }4.2 基于变更集的CI优化# GitHub Actions配置示例 jobs: build: runs-on: ubuntu-latest steps: - uses: changesets/actionv1 with: publish: npm4.3 大仓库性能优化启用Git的sparse-checkoutgit config core.sparseCheckout true echo apps/frontend/* .git/info/sparse-checkout使用git fsck定期检查仓库健康状态5. 常见问题解决方案5.1 权限管理难题通过.gitattributes实现细粒度控制/libs/sensitive/** linguist-vendored5.2 二进制文件处理使用Git LFS管理大文件git lfs track *.psd5.3 子团队协作冲突推荐的分目录结构monorepo ├── team-a │ ├── apps │ └── libs └── team-b ├── apps └── libs6. 迁移后的效能提升在最近的一个中台项目中迁移到单仓库后构建时间从45分钟降至12分钟依赖共享代码重复率从18%降到5%跨团队协作PR量增加300%最让我惊喜的是发现多个团队不约而同开发了相似的utils库合并后节省了约2万行冗余代码。这种发现只有在单仓库的全局视角下才可能实现。
