Working solo doesn't mean you should skip good git practices. Future you will thank present you.

Why Bother?

"I'm the only one on this project. Why not just commit to main?"

Because:

  • You'll want to undo things
  • You'll forget what you did
  • You might add collaborators later
  • Good habits transfer to team projects

Commit Messages That Help

Bad:

fix bug
updates
wip
asdf

Good:

fix: prevent crash when user list is empty
feat: add email validation to signup form
refactor: extract payment logic to separate module
docs: update API examples for v2 endpoints

You'll read these messages in six months wondering "what was I thinking?" Make them useful.

The Conventional Commits Pattern

I use prefixes:

  • feat: - new feature
  • fix: - bug fix
  • refactor: - code change that doesn't add features or fix bugs
  • docs: - documentation
  • test: - adding tests
  • chore: - maintenance (deps, config)

Optional but helpful. Makes history scannable.

Branching Strategy

Even solo, branches help.

Simple Approach

# Main is always deployable
git checkout -b feature/new-thing
 
# Work on feature
git commit -m "feat: add new thing"
git commit -m "feat: refine new thing"
 
# Merge when done
git checkout main
git merge feature/new-thing
git branch -d feature/new-thing

When to Branch

  • New features
  • Risky experiments
  • Anything you might abandon

Don't branch for:

  • Typo fixes
  • Small config changes
  • Obvious one-liners

Commit Frequently

Small commits are easier to:

  • Understand
  • Revert
  • Cherry-pick
  • Review later
# Instead of one big commit at end of day
git commit -m "implement entire user system"
 
# Prefer many small commits
git commit -m "feat: add user model"
git commit -m "feat: add user creation endpoint"
git commit -m "feat: add user validation"
git commit -m "test: add user creation tests"

Use Tags for Releases

# Tag releases
git tag -a v1.0.0 -m "Initial release"
git push origin v1.0.0
 
# List tags
git tag -l
 
# Checkout a specific version
git checkout v1.0.0

Tags make it easy to:

  • Find specific versions
  • Deploy known states
  • Track what's in production

The Stash is Your Friend

Working on something but need to switch context?

# Save current work
git stash
 
# Do other things
git checkout other-branch
# ... work ...
git checkout original-branch
 
# Restore your work
git stash pop

Better than committing half-done work.

Rebase vs Merge

For solo work, both are fine. I prefer:

Merge for completed features:

git checkout main
git merge feature/thing

Rebase to clean up before merging:

git checkout feature/thing
git rebase -i main
# Squash messy commits, reword messages
git checkout main
git merge feature/thing

Interactive Rebase for Cleanup

Before sharing code, clean up your history:

git rebase -i HEAD~5

In the editor:

  • pick - keep commit
  • squash - combine with previous
  • reword - change message
  • drop - remove commit

Turn "wip", "fix typo", "actually fix it" into one clean commit.

Useful Aliases

Add to ~/.gitconfig:

[alias]
  s = status -sb
  co = checkout
  cm = commit -m
  last = log -1 HEAD
  undo = reset HEAD~1 --mixed
  amend = commit --amend --no-edit
  lg = log --oneline --graph --decorate -20

Now:

  • git s - quick status
  • git cm "message" - commit with message
  • git undo - undo last commit, keep changes
  • git amend - add to last commit
  • git lg - pretty log

.gitignore From Day One

Don't commit:

  • .env files
  • node_modules/
  • __pycache__/
  • IDE settings
  • Build artifacts

Use gitignore.io to generate good defaults.

My Daily Workflow

# Start of day - check status
git status
git log --oneline -5
 
# Start feature
git checkout -b feature/thing
 
# Work and commit frequently
git add -p  # Stage interactively
git commit -m "feat: partial progress"
 
# End of day - push even if not done
git push -u origin feature/thing
 
# Feature complete
git checkout main
git merge feature/thing
git push
git branch -d feature/thing

Common Mistakes to Avoid

Committing secrets

  • Use .env files, add to .gitignore
  • If you commit a secret, rotate it immediately

Giant commits

  • Commit early and often
  • One logical change per commit

Meaningless messages

  • Write for future you
  • Include the "why" when not obvious

Never pushing

  • Push daily at minimum
  • Your laptop isn't a backup

The Golden Rule

If you ever think "I should probably commit this," commit it.

You can always squash later. You can't recover uncommitted work.

React to this post: