My Git Workflow for Solo Projects
When you’re the only person on a project, git discipline is easy to skip. Here’s why I still bother and what I actually do.
Commit messages
I follow a lightweight version of Conventional Commits:
feat: add tag filtering to post list
fix: correct date sorting order
chore: update dependenciesThe type prefix makes git log --oneline scannable at a glance and makes it trivial to generate a changelog later.
Branch strategy
For solo work I keep it simple:
main— always deployablefeat/<name>— anything that takes more than one commit
I squash-merge feature branches so main stays linear. This makes git bisect actually useful.
What I skip
- Pull request reviews (it’s just me)
- Branch protection rules on
main - Semantic versioning for internal tools
The goal is a clean history that helps future me understand why a change was made, not process for its own sake.
One rule I always keep
Write the commit message before you write the code. Sounds backwards, but it forces you to clarify what you’re actually trying to do, and it keeps commits focused.