Git Workflow for Solo Developers

Most Git workflow advice is written for teams. Gitflow, trunk-based development, pull request reviews -- these processes exist to coordinate multiple people working on the same codebase. When you are the only developer, a lot of that ceremony is waste. But committing everything to main with messages like "stuff" and "fix" is the other extreme, and your future self will pay for it.

Here is a Git workflow for solo developers that is disciplined enough to be useful but lightweight enough that you will actually follow it.

The Solo Branch Strategy

Use two types of branches:

main -- always deployable. This is what is live on your site or available for download.
Feature branches -- short-lived branches for specific changes. Name them descriptively: add-sudoku-game, fix-unicode-encoding, update-navbar.

# Start a new feature
git checkout -b add-dark-mode

# Work on it, commit as you go
git add .
git commit -m "add dark mode toggle to settings page"

# When done, merge to main
git checkout main
git merge add-dark-mode
git branch -d add-dark-mode

Why bother with branches when you are the only developer? Two reasons. First, it keeps main clean. If you start a feature, realize it is a bad idea halfway through, and want to abandon it, you just delete the branch. No messy reverts on main. Second, it creates a natural grouping of related commits that makes the history readable.

Skip pull requests. They exist for code review, and you cannot meaningfully review your own code in a PR. Just merge locally.

Commit Hygiene

Good commit messages are the single most valuable Git habit for a solo developer. When you come back to a project after three months and need to understand why something was changed, the commit log is your only documentation.

Rules that work:

Start with a verb in imperative mood. "Add dark mode toggle," not "Added dark mode toggle" or "Adding dark mode toggle." This matches Git's own convention (e.g., "Merge branch...").
Keep the first line under 72 characters. This is not arbitrary -- it is the width that displays correctly in git log --oneline, GitHub, and most Git tools.
Separate "what" from "why" when the change is not obvious. The first line says what changed. A blank line followed by a paragraph explains why, if needed.

# Good
git commit -m "fix btoa() failing on Unicode input

btoa() only accepts Latin-1 characters. Use TextEncoder
to convert to UTF-8 bytes first, then base64-encode the
byte string."

# Bad
git commit -m "fix bug"
git commit -m "updated stuff"
git commit -m "WIP"

Commit frequency: commit when you have completed a logical unit of work. Not after every line change, not after an entire feature. A good commit should be independently understandable and, ideally, independently revertable.

Tags for Releases

If your project has any concept of versions (even informal ones), use Git tags:

# Lightweight tag for simple versioning
git tag v1.2.0

# Annotated tag with a message
git tag -a v1.2.0 -m "Add dark mode, fix Unicode encoding"

# Push tags to remote
git push origin --tags

Tags give you instant rollback capability (git checkout v1.1.0) and make it trivial to see what changed between versions (git log v1.1.0..v1.2.0). For side projects, even tagging major milestones (not every patch) is better than nothing.

The .gitignore Habit

Set up .gitignore before your first commit, not after you accidentally commit node_modules/ or .env. A starting point for most projects:

# Dependencies
node_modules/
.venv/
vendor/

# Environment
.env
.env.local

# Editor
.vscode/
.idea/
*.swp
*~

# OS
.DS_Store
Thumbs.db

# Build output
dist/
build/
*.min.js.map

If you already committed files that should be ignored, git rm --cached <file> removes them from tracking without deleting the local copy.

Useful Aliases

A few Git aliases save real time over a week of development:

git config --global alias.s "status --short"
git config --global alias.lg "log --oneline --graph --all -20"
git config --global alias.amend "commit --amend --no-edit"
git config --global alias.undo "reset HEAD~1 --mixed"

git s -- compact status, shows just the changed files
git lg -- visual branch graph, last 20 commits
git amend -- add staged changes to the last commit without changing the message
git undo -- undo the last commit but keep the changes in your working directory

Remote Backup

Push to a remote repository (GitHub, GitLab, whatever) after every work session. This is not about collaboration -- it is about backup. Your laptop's hard drive can fail. A remote repository means your code survives hardware failure, theft, or accidental deletion.

The workflow for a solo developer is simple: work locally, push when you are done for the day. No pull requests, no CI pipeline (unless you want one), no branch protection rules. Just git push as insurance.

A good Git workflow for solo projects is not about following team processes. It is about building habits that make your own history readable, your deployments safe, and your work recoverable. These habits take almost no extra time but save hours when something goes wrong or when you need to understand code you wrote months ago.