A Practical Git Workflow for Solo Developers

If you work on your own projects, a heavyweight Git workflow with pull-request reviews and trunk policies is overkill. What you actually need is a simple routine that keeps your history readable and makes mistakes recoverable. Here's the one I use daily.

1The one-line setup

Tell Git who you are and pick your default branch name once:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase true

init.defaultBranch main makes new repos start on main instead of master.
pull.rebase true keeps history linear when you git pull — no merge bubbles.

2A working routine

The rhythm that scales from tiny scripts to real projects:

git init                 # once, in the repo root
git add .                # stage everything
git commit -m "..."      # save a point

Commit when a logical unit is done — a feature, a bugfix, a doc edit — not after ten hours of everything. Small commits are easy to review, bisect, and revert.

3Write commits worth reading

A good message says why and what, not how:

Add dark mode to the settings page

The old theme had no contrast control, which hurt readability at night.
Use CSS custom properties so the palette is overridable per-user.

Capitalize the subject line, keep it under ~50 chars.
Leave a blank line, then explain why if it's not obvious.
Don't be afraid of multi-line messages opened in an editor (git commit with no -m).

4Branch before anything risky

A branch is just a bookmark on a line of history. Use one for experiments or anything you might want to throw away:

git checkout -b try-new-approach   # create + switch
# ... experiment ...
git checkout main                  # back to safety
git branch -d try-new-approach    # delete it (it was throwaway)

If the experiment worked, merge it:

git checkout main && git merge try-new-approach

5See what you're doing before you commit

The two commands that prevent 90% of Git accidents:

git status      # what changed / what's staged / what's untracked
git diff        # the actual content of unstaged changes

git diff --staged shows what's about to be committed. Checking this before git add . && git commit catches stray files (think .env secrets or build output) before they land in history.

6Never commit secrets

Templates, build dirs, and credentials don't belong in the repo. List them in .gitignore:

touch .gitignore

.env
node_modules/
dist/
*.log

Commit the .gitignore early: git add .gitignore && git commit -m "Add gitignore". If you did commit a secret, change the secret and clean history — don't just delete the file (it stays in history).

7Recovering when it goes wrong

You'll make a mess eventually. These are the escape hatches:

git checkout -- <file>       # discard unstaged changes to one file
git reset --soft HEAD~1      # undo last commit, keep changes staged
git reset HEAD~1             # undo last commit, keep changes (unstaged)
git reflog                   # your safety net: every move you've made

git reflog is the one to remember — even after a bad reset or branch delete, it lists where your HEAD used to be, and you can go back with git reset --hard <hash>.

The rule of thumb

If you only take three things from this: commit small and often, write messages that explain why, and know that git reflog can rescue you when you think you've lost work. That's enough for most solo projects — the rest you pick up when you need it.