How We Moved to a Monorepo
summary
Describes consolidating six GitHub repositories into one mono-repo to make cross-repo edits atomic and reduce spurious CI failures for a Linux-scale codebase with 3,706 forks. The team first tried an "atomic push" hack, then grafted histories and moved files into subfolders without rebasing to preserve forks; after finding Google’s Capibara too slow, they implemented a custom Git-object-based importer and deployed it successfully.
AI-written summary · about
chapters (5)
related talks
29mOne for all, all for one: The Journey to Android Monorepo
40mMonorepo or Polyrepo: What's the Right Choice for You?
15mPanel discussion: Mono-repo Vs. Multi-repo Vs. Hybrid
30mForget Mono vs. Multi-Repo: Building Centralized Git Workflows for All Apps
06mHow I Learned to Stop Worrying and Love the Mono Repo
25mMicroservices, Monorepos, and the Efficient Build Processes
08mLightning Talk: Managing the ‘Git’ Half of ‘GitOps’: How to Structure...
09mLightning Talk: Best Practices on Organizing GitOps Repositories