Keeping everything in one repository sounds clean: one repo to clone, one place to back up.
In practice, mono-repos become junk drawers fast.
If you’re running a small stack — Hugo site, config files, automation scripts — a single repo is fine, but only if you design for it.
Why a Mono-Repo?
For a one-person operation, it’s practical:
- Easier to version control across projects
- Simpler backup and migration
- One history to follow when debugging changes
But convenience only works if you avoid chaos.
Partition by Directory, Not Just Gut Feel
Structure matters:
content/for your siteinfra/for configs and scriptsdocs/for notes and playbooksarchive/for decommissioned files
Every directory should have a README that explains what lives there and why.
Use Branches for Work-in-Progress
Don’t litter the repo with half-finished experiments in main.
Use feature branches or even a scratch branch. Merge only when stable.
Your future self will thank you when you can roll back without digging through noise.
Commit Messages Are Index Entries
A mono-repo is only as searchable as its commit history:
- Write messages that explain the why, not just the what
- Reference linked changes (e.g. “updated Hugo theme and nginx config to match”)
- Treat commits as breadcrumbs for future debugging
Automate What You Can
A small Makefile or script at the repo root saves time:
- Build and deploy commands
- Backup triggers
- Linting or Hugo preview shortcuts
If it takes more than two steps, script it and commit the script.
Mono-Repo Discipline
A mono-repo works when it has discipline baked in:
clear structure, meaningful commits, documented purpose.
Without that, it becomes a landfill.
Version control is meant to give clarity, not hide the mess.
Keep the mono-repo lean, or split it before it eats you.