Mono-Poly
Pragmatic code re-organization across repositories.
We've all been in monorepo vs polyrepo discussions. They all share the same hidden assumption: that it's a one-and-done decision. But code structure should serve business demands and organization structure — and those change. So never marry a specific method of code organization.
In most cases just start coding a new thing in an existing repo. As
you learn more about business needs or the organization changes, consider moving it around.
Break a monorepo, merge two repos, move code between repos. Whatever.
Git history
"If I move code to another repo, I lose my git history". Well, no.
With git filter-repo and git merge --allow-unrelated-histories, code carries its
full commit history through every move (so git blame works). Use this CLI tool if you want.
AI
AI agents work better with focused codebases. Noise in codebases may cause AI to do things it shouldn't.
Business domains
New domains may appear, some will consolidate or flat out disappear. At times side-concerns become core. Repo boundaries should track those shifts, not freeze the state that was true 3 years ago.
Organization structure
Conway's Law is real, and it impacts repo structure as well. Code location should match ownership.
Compromises
Moving code around means refactoring and introducing dependencies. It's not a bad thing if it's for sake of business needs or organization structure. Good engineering is all about making compromises.