Before you come at me with pitchforks: I'm not saying branches are bad. They're essential for teams. What I'm saying is that for solo projects, the standard Git Flow workflow (feature branches, pull requests, merge commits) adds overhead that gives you almost nothing in return.

Who am I opening pull requests for? Myself? Am I going to review my own code and leave a comment saying "looks good to me"? That's just talking to yourself with extra steps.

The Solo Workflow I Actually Use

  1. One branch: main. That's it.
  2. Small, frequent commits: Every 15-30 minutes of work = one commit with a descriptive message.
  3. Tags for milestones: git tag v0.1 when something is stable.
  4. Stash for context switches: git stash if I need to quickly fix something else.
# My actual workflow
git add -A
git commit -m "add search filter to posts grid"
git push

# That's it. No branch. No PR. No merge commit.

But What If I Break Something?

This is the main argument for branches: "what if your feature breaks main?" Here's the thing — if you're committing frequently, you can always:

# See what changed
git log --oneline -10

# Undo the last commit (keep changes in working directory)
git reset HEAD~1

# Or go nuclear and revert to a specific commit
git revert abc1234

Small, frequent commits give you the same safety net as branches but with zero overhead. Each commit is effectively a "checkpoint" you can roll back to.

When I DO Use Branches

I'm not completely branch-free. There are two cases where I create a branch:

  • Risky experiments: "I wonder if rewriting the CSS Grid to Flexbox would be better?" Branch it, try it, delete if it sucks.
  • Deploying to production: If my project has auto-deploy on push to main, I'll work on a dev branch and merge when ready.

But these are exceptions, not the rule. 90% of my solo work happens on main.

The Commit Message Discipline

Without branches, your commit messages become your project history. Make them count:

# Bad
git commit -m "stuff"
git commit -m "fix"
git commit -m "wip"

# Good  
git commit -m "add dark mode toggle to footer"
git commit -m "fix mobile nav overflow on small screens"
git commit -m "optimize hero image loading with lazy attr"

Good commit messages replace branch names, PR descriptions, and code review comments — all in one line.

The Productivity Boost

Since dropping branches for solo work, I've noticed:

  • Less context switching: No "which branch am I on?" confusion
  • Faster deploys: Commit + push = live. No merge ceremony
  • Cleaner history: Linear commit log vs merge commit spaghetti
  • Less cognitive load: One less decision to make every time I start working

The Rule of Thumb

If you're the only person writing code and reviewing code and deploying code — you don't need a workflow designed for 10-person teams. Use the simplest process that keeps you safe.

For me, that's: commit often, push to main, tag milestones. Everything else is theater.