Managing a monorepo in Git requires strategies that keep clone times fast, working directories focused, and commits attributable to specific packages — problems that become severe as the repository grows. As the creator of CoreUI with 25 years of open-source development experience, I manage a monorepo with multiple framework packages and rely on sparse checkout, shallow clones, and conventional commits to keep the workflow efficient. The key techniques are: sparse checkout to only fetch files you need, partial clone to avoid downloading all objects, and conventional commit prefixes to identify which package each commit affects. Git’s built-in tools handle all of this — no third-party tooling required for the Git layer itself.

Splitting a monorepo into separate repositories is a common scaling decision when a codebase grows and different teams need independent release cycles. As the creator of CoreUI with 25 years of open-source development experience, I split the CoreUI monorepo into framework-specific packages and preserved the commit history for each component, which was essential for tracking bug history and attribution. The tool for this is git filter-repo, which can extract a subdirectory into a new repository with its full commit history. The result is a standalone repository containing only the commits that touched the extracted directory.