As systems grow, the “one repo per microservice” pattern can lead to significant overhead: dependency hell, fragmented CI/CD, and difficulty in cross-service refactoring. Migrating to a monorepo often becomes the logical next step for many engineering teams.

Monorepo Migration

The biggest technical challenge during this migration is preserving the commit history of each individual service. You don’t want to just copy files; you want to bring the years of context, bug fixes, and development history with them.

Managing dotfiles on Windows can be a challenge if you want to keep your home directory clean without relying on symlinks or complex management tools. A “Git Bare Repository” approach allows you to track configuration files (like .gitconfig, .vimrc, or PowerShell profiles) directly in their original locations.

The Bare Repository Concept

A bare repository is a Git repository without a working directory. By pointing the “working tree” to your home directory while keeping the “git directory” separate (e.g., in ~/.cfg), you can manage your files across the system as if they were in a single repo, without Git interfering with other files in your home folder.

The two common patterns to forking a module are (1) forking via a separate repo or (2) vendoring, which forks all deps into the current module (or app). I recommend a third approach to forking using git subtree and go mod edit -replace. It’s very similar to repo forking without the repo

Let’s say you’ve made modifications to github.com/tj/go-spin. Once preserving changes in a repo is needed, use git subtree to move the fork into your monorepo, or app repo