Git Workflow for Solo Founders

When you're the only engineer, most git advice doesn't apply. You don't need branch protection rules. You don't need pull request reviews. You don't have merge conflicts because there's nobody to conflict with.

But git discipline still matters. Future-you reading the history is a different person. Here's the workflow I've settled on after building multiple products solo.

trunk-based with short-lived branches

I work on main for small changes — quick fixes, copy updates, config changes. Anything I can finish in under an hour goes straight to trunk.

For features that take longer, I create a branch, work on it for a day or two max, and merge. No long-lived feature branches. They rot. The longer a branch lives, the more it diverges from main, and the harder the merge.

# Small fix: commit directly to main
git add src/components/Button.tsx
git commit -m "fix: button focus ring missing in dark mode"
 
# Feature: short-lived branch
git checkout -b feat/question-bank-search
# ... work for a day ...
git checkout main
git merge feat/question-bank-search
git branch -d feat/question-bank-search

No rebasing. No squash merges. Just merge and move on. The commit history is a log of what happened, not a curated narrative.

conventional commits, always

Every commit follows the format: type: description. Types: feat, fix, refactor, docs, test, chore, perf, ci.

feat: add LLM interaction mode to candidate workspace
fix: auto-save race condition on concurrent submissions
refactor: extract markdown normalization to shared utility
test: add integration tests for scoring pipeline
docs: update API contract for assessment creation
chore: bump next.js to 15.1.2
perf: lazy-load Three.js on hero section only
ci: add typecheck step to build pipeline

This isn't about being neat. It's about making git log --oneline useful. When something breaks, I can scan the last 20 commits and immediately identify which ones touched what. feat commits add behavior. fix commits change behavior. refactor commits shouldn't change behavior at all. That distinction matters when you're bisecting a bug.

commit messages that help future-you

The description should answer "what changed" in under 70 characters. If you need to explain "why," use the commit body:

fix: assessment timer continues after manual submission

The countdown timer was checking `isExpired` but not `isSubmitted`.
After a candidate manually submitted, the timer kept running and
triggered auto-submit 30 seconds later, creating a duplicate submission.

Fixes #47

The body is optional. Most commits don't need it. But when the fix is non-obvious — when future-you will look at the diff and wonder "why did I change this?" — the body saves hours of re-investigation.

tag your releases

Even without a formal release process, tagging stable states is valuable:

git tag -a v0.1.0 -m "MVP: assessment creation + candidate flow"
git tag -a v0.2.0 -m "LLM interaction mode + scoring pipeline"

If something breaks catastrophically, git checkout v0.1.0 puts you back in a known-good state instantly. Without tags, you're scrolling through commit history trying to find "the one where everything worked."

commit early, commit often

My rule: if I've made a change I don't want to lose, I commit it. Even if it's incomplete. Even if the tests don't pass. I can always amend, squash, or rewrite later (though I rarely do).

Small, frequent commits make git bisect actually useful. If each commit is 500 lines touching 12 files, bisecting is pointless — you still have to search the whole commit. If each commit is 20-50 lines with a clear description, bisect pinpoints the problem in seconds.

the .gitignore that matters

Start every project with this:

node_modules/
.env
.env.local
.env*.local
.next/
dist/
build/
.DS_Store
*.log
.vercel
.supabase
coverage/
.worktrees/

Add to it as you go. But never commit node_modules, never commit .env files, and never commit build output. These three rules prevent 90% of git disasters I've seen in solo projects.

what doesn't matter

Branch naming conventions. PR templates. Merge strategies. Code owners files. These are coordination mechanisms for teams. Solo, they're overhead with no benefit.

Keep it simple: conventional commits, short-lived branches, tags for milestones. That's enough git discipline for one person shipping a product.