How to Organize Code Across Git Repositories
Ground rules for deciding what deserves its own Git repository, how to name it, and how to keep experimental code out of the core product.
Splitting code across repositories is one of those decisions that’s cheap to get right early and annoying to fix later. A few rules of thumb make the decision less ad hoc:
Use a dedicated repository per scope
Each distinct scope of code deserves its own Git repository. This lines up with the same thinking behind the package principles (cohesion, coupling, and stable dependencies) — cohesion within a repository, clean separation between them.
Separate core product from everything else
Draw a clear line between your core product and additional helper, PoC, or exploratory content, and route each into the most appropriate project. A common pattern: Product for the product itself, Product_Sandbox for exploration, Product_Tools for supporting tooling. The point isn’t the specific names — it’s keeping the core product repository free of things that aren’t actually the product.
Keep naming consistent
A few small conventions go a long way:
- Avoid characters known to cause trouble in URLs — spaces being the obvious offender.
- Use
.to separate distinct contexts within a title. - Prefix “Proof of Concept” repositories with
Poc—Poc.IdentityServer, for example — so they’re unmistakable at a glance, and easy to filter out of a repository list when you don’t want the noise.
None of this is complicated, but it’s the kind of consistency that only pays off if everyone actually follows it. Worth writing down once and pointing people to, rather than re-litigating per repository.
See also the note on the DevTree layout for how this fits into the bigger picture of organizing a project’s files.