Git Workflow for Solo Developers

Introduction

Most Git resources are written for teams. Branching strategies like Git Flow, Trunk Based Development, and three-way merges make a lot of sense when you have five people working on the same codebase simultaneously. When you're working alone, applying those patterns wholesale is overkill — but having no workflow is worse.

After years of solo development, I've settled on a set of practices that keep my projects clean, make it easy to recover from mistakes, and produce a commit history that's actually useful rather than a wall of "fix", "update", and "wip". This post covers what that looks like in practice.

Core Concepts

Your Commit History Is Documentation

The most important mental shift for solo developers is understanding that commit messages are future documentation. Not for other developers (today) — but for yourself in three months, or when you open a bug report and need to understand what changed and why.

A bad commit history:

fix
update styles
wip
more stuff
done
actually done now

A useful commit history:

feat: add contact form with email validation
fix: resolve hydration mismatch on dark mode toggle
refactor: extract API client into separate module
chore: update Next.js to 14.2.0
docs: add deployment instructions to README

That second history tells a story. You can git log --oneline and understand the evolution of the project without opening a single file.

Conventional Commits

Conventional Commits is a lightweight specification for commit message format:

<type>[optional scope]: <description>

[optional body]

[optional footer]

• feat — new feature
• fix — bug fix
• refactor — code change that neither fixes a bug nor adds a feature
• chore — maintenance, dependency updates, tooling changes
• docs — documentation only
• style — formatting, whitespace (no logic change)
• test — adding or modifying tests
• perf — performance improvement

This structure is also machine-readable — tools like semantic-release and standard-version can automatically generate changelogs and bump version numbers based on your commit history.

Practical Examples

My Daily Workflow

# Start of a work session
git status                    # See where things are
git log --oneline -10         # Quick history recap

# During work
git add -p                    # Patch-stage — choose exactly which changes to add
git commit -m "feat: implement dark mode toggle"

# Before finishing
git diff HEAD                 # Review everything since last commit