A pragmatic git workflow for solo projects

Most git advice is written for teams. For solo projects you can get 95% of the value with almost no ceremony. This is the setup I use on every side project.

The rules

1. main is always deployable. No exceptions.
2. Short-lived branches for anything nontrivial.
3. Commit messages in the imperative, as if giving an order.
4. Squash-merge, so history reads like a changelog.

The daily loop

git switch -c fix/retry-backoff
# ...work...
git add -p            # stage deliberately, not with -A
git commit -m "Add exponential backoff to retries"
git switch main && git merge --ff-only fix/retry-backoff && git push
git branch -d fix/retry-backoff

Fast-forward merges keep history linear and git bisect actually useful.

Three aliases that earn their keep

git config --global alias.lol "log --graph --oneline --decorate --all"
git config --global alias.amend "commit --amend --no-edit"
git config --global alias.undo "reset --soft HEAD~1"

• git lol — the entire history, readable.
• git undo — take back the last commit, keep the changes staged.
• git amend — you forgot a file. We’ve all been there.

On commit messages

For solo work, one honest sentence beats seven sections of template. Write the message for the version of you that reads this in eighteen months, with no context and a failing test.

“Fix bug” is a message for no one. “Skip retry when upstream returns 4xx” is a message for someone.

What I deliberately skip

PR templates, review gates, conventional-commit linting, release branches. All of it is scaffolding for coordination, and when you work alone, you don’t have coordination problems — you have focus problems. Optimize for focus.