The Git Workflow That Keeps Me Sane as a Solo Developer

Most git workflow guides assume a team. Feature branches, pull requests, code reviews — great for teams, overkill for solo work. But working solo does not mean you should just commit everything to main. Here is what I actually do.

The Workflow

I use a simple branch-per-feature approach with no pull requests:

# Start a new feature
git checkout -b add-contact-form

# Work, commit often with clear messages
git commit -m "Add contact form component with validation"
git commit -m "Wire contact form to REST API endpoint"
git commit -m "Add success/error states and loading indicator"

# When done, merge to main
git checkout main
git merge add-contact-form
git branch -d add-contact-form

Commit Message Convention

I keep messages short but descriptive. Start with an action verb: Add, Fix, Update, Remove, Refactor. The first line answers “what changed and why” in under 72 characters. If I need more context, I add a blank line and a body paragraph.

Tags for Deployments

Instead of a release branch, I tag commits that go to production:

git tag -a v1.2.0 -m "Add contact form and project inquiry endpoints"
git push origin v1.2.0

This gives me a clean deployment history without the overhead of release branches. If something breaks in production, I can instantly see what changed between tags.

The One Rule

Never commit directly to main while working on a feature. Even solo, branches give you the freedom to abandon work, switch context, and keep main always deployable. It takes 5 seconds to create a branch and saves hours of headaches.