Skip to main content
Back to blog

Git workflows that actually work for solo developers

·3 min readDeveloper Tools

Most git workflow guides assume you are on a team. Feature branches, pull requests, code reviews, release branches. That is great for teams, but when you are the only developer, most of that process is overhead.

Here is what actually works when you are flying solo.

Keep it simple: main + feature branches

You do not need Git Flow, GitHub Flow, or trunk-based development in their formal definitions. What works:

  1. main is always deployable
  2. New features get a branch
  3. Merge when done
  4. Delete the branch
git checkout -b add-user-auth
# work, commit, work, commit
git checkout main
git merge add-user-auth
git branch -d add-user-auth
git push

No pull requests, no code reviews (there is no one to review). The branch exists to keep work-in-progress separate from deployable code.

When to branch vs commit directly to main

Branch when the work will take more than one session or when you might need to abandon it. Direct commits to main are fine for small fixes, config changes, and minor updates.

The test: if you might want to git stash this work to do something else, it should be a branch instead.

Commit messages that help future you

When you are the only developer, commit messages are notes to your future self. "fix bug" is useless in three months. Be specific:

# Bad
git commit -m "fix bug"
git commit -m "update styles"
git commit -m "wip"
 
# Good
git commit -m "fix: prevent duplicate form submission on slow connections"
git commit -m "update: increase card padding on mobile breakpoint"
git commit -m "feat: add email validation to signup form"

The prefix (fix/feat/update) is optional but helps when scanning git log.

Use tags for releases

If you deploy manually or need to track versions, tags are simpler than release branches:

git tag -a v1.2.0 -m "Add user authentication"
git push --tags

You can always check out a tag if you need to see what was deployed at a specific point.

The stash is your friend

Working on something and need to switch context? Stash it:

git stash push -m "half-finished auth refactor"
# do the urgent fix on main
git stash pop

Name your stashes. git stash list with unnamed stashes is impossible to navigate.

Interactive rebase for clean history

Before merging a feature branch, clean up the commits:

git rebase -i main

Squash the "wip" and "fix typo" commits into meaningful ones. Your future self will thank you when reading git log.

Backups

Push to a remote regularly. Your local git repo is not a backup. If your drive dies, unpushed commits are gone.

I push at least daily, even for work-in-progress branches. GitHub and GitLab repos are free and serve as offsite backups for your code.

What I skip

  • Pull requests (no one to review them)
  • Branch protection rules (unnecessary friction for one person)
  • Squash merges from the GitHub UI (I clean up with interactive rebase locally)
  • Changelog generation tools (overkill for solo projects)

The goal is a clean, navigable history with minimal process overhead. Every workflow step should save you more time than it costs.

Sources

Enjoying the blog? Subscribe via RSS to get new posts in your reader.

Subscribe via RSS