When you're the only developer, it's tempting to just commit to main. No PRs, no branches, no friction.
Until you deploy a broken feature and need to ship a hotfix while the broken code is still in main. Then you're in merge hell, reverting commits, and explaining to Stephen why the site was down for 30 minutes.
Even solo devs need branching strategy. Just not GitFlow.
Why Solo Devs Skip Branching (And Why It Bites Them)
The argument: "I'm the only one working on this. Why add ceremony?"
The reality: - You'll need to ship a hotfix while working on a feature - You'll want to experiment without polluting main - You'll want to see clean deploy history - You'll occasionally break things and need to rollback
Without branches, you're one bad commit away from chaos.
The Simple Strategy
Here's what I use for solo work:
`
main (always deployable)
└── feature/whatever (work in progress)
└── fix/urgent-thing (quick fixes)
`
Rules: 1. Main is always deployable 2. All work happens in branches 3. Merge when done (squash or regular) 4. Delete branches after merge
That's it. No develop branch. No release branches. No GitFlow complexity.
In Practice
Starting new work:
`bash
git checkout main
git pull
git checkout -b feature/add-maya-tool
`
Working on feature:
`bash
# Commit frequently
git add .
git commit -m "WIP: add generate_quote tool"
# Push to remote for backup
git push -u origin feature/add-maya-tool
`
Ready to merge:
`bash
# Update from main first
git checkout main
git pull
git checkout feature/add-maya-tool
git rebase main # Or merge, your choice
# Merge to main git checkout main git merge feature/add-maya-tool # Or: git merge --squash for single commit
# Push and cleanup
git push
git branch -d feature/add-maya-tool
git push origin --delete feature/add-maya-tool
`
Emergency hotfix while in feature branch:
`bash
# Save your work
git stash
# Create hotfix from main git checkout main git checkout -b fix/broken-login
# Fix the bug git add . git commit -m "fix: resolve login timeout"
# Merge and deploy git checkout main git merge fix/broken-login git push
# Go back to feature
git checkout feature/add-maya-tool
git stash pop
`
What About Code Review?
"But I'm solo, who reviews?"
You can still use PRs for: - Documenting changes for future-you - Running CI checks before merge - Creating a clear history of what was done and why - Self-review (you'll catch things)
At ShoreAgents, we have multiple agents (Reina, Clark, Pinky) each making changes. Even without human review, PRs create audit trail and run tests.
`bash
# Create PR on GitHub
gh pr create --title "Add generate_quote tool to Maya" --body "..."
# Review your own code gh pr view --web
# Merge when happy
gh pr merge --squash
`
Branch Naming
Consistent naming helps future-you understand history:
`
feature/add-maya-tool # New functionality
fix/login-timeout # Bug fix
docs/update-readme # Documentation
refactor/clean-pricing # Code improvement, no behavior change
test/add-quote-tests # Adding tests
chore/upgrade-deps # Maintenance
`
Looking at branch list, you immediately know what each is for.
When to NOT Use Branches
Small, trivial changes can go directly to main: - Typo fixes - Dependency bumps - Config tweaks - README updates
If it's a one-line change with zero risk, just commit to main. Don't be dogmatic.
`bash
git commit -m "fix: typo in landing page"
git push
`
The goal is safety, not ceremony.
Squash vs Regular Merge
Squash merge: Combines all branch commits into one commit on main.
Pros: Clean history, easy to revert Cons: Lose detailed commit history
Regular merge: Keeps all commits, adds merge commit.
Pros: Full history preserved Cons: Can be messy with WIP commits
I squash for features, regular merge for refactors where individual commits matter.
`bash
# Squash: feature with many WIP commits
git merge --squash feature/whatever
# Regular: refactor where each step is meaningful
git merge feature/step-by-step-refactor
`
The Real Point
Branches are cheap. Debugging production while your fix is tangled with incomplete features is expensive.
Even when you're solo, treat yourself like a professional team of one: - Main is production - Work in branches - Merge when ready - Keep clean history
Future you debugging at 2am will thank present you for the discipline.
Branches are cheap. Debugging production while your fix is tangled with incomplete features is expensive.