🧼 Git Hygiene for Solo Builders: Think Like a Product, Build Like a Dev

By Jeremy Geiger
Founder of ProductBuilt, solo app builder, former VP of Product, full-stack curious

When you start building solo — especially if you’re coming from a technical product management background — you quickly realize just how much Git matters.

Not in a theoretical way. In a this-will-save-your-butt kind of way.

Git isn’t just a developer’s tool. It’s a solo builder’s journal, parachute, safety net, and versioned memory. But it only works if you use it well. If you’re treating it like a backup system or only pushing when things “work,” you’re missing most of the leverage it offers.

In this post, I’ll show you how to use Git to your advantage as a solo builder, and why deleting your branches after merging is a power move, not a mistake.

🧱 Git for Solo Builders: Think Modular, Commit Often

Solo building is its own beast. You wear the hat of architect, engineer, designer, QA, and PM — sometimes in a single afternoon. Your Git history should reflect that journey.

Here’s a quick mindset shift:

Old Mindset	New Git-Friendly Mindset
“I’ll push when it works”	“Every meaningful thought gets a commit”
“Branches are for teams”	“Branches are for ideas and experiments”
“I don’t need version control locally”	“Git is my undo button, my journal, and my test lab”

✅ Pro Tips:

Commit Frequently, but Cohesively: A commit should represent one logical unit of change. That way, if you need to undo it, you’re not untangling unrelated work.
Write Descriptive Messages: Skip the “fix stuff” messages. Your future self will thank you. Try:
git commit -m "✨ Add tray icon toggle for recording state"
Use Branches for Experiments and Features: Keep branches short-lived and focused. Use naming conventions like feat/clipboard, bug/fix-mic.

🌳 What to Do With Branches After You Merge?

Delete your merged branches. You won’t regret it.

As a solo builder, it might feel scary. Like deleting old work. But Git doesn’t lose anything unless you make it.

🔥 Why You Should Delete Merged Branches:

Keeps your workspace clean
Avoids confusion over active work
Preserves history via merge commits

# Delete locally
git branch -d feat/audio-recorder

# Delete remotely
git push origin --delete feat/audio-recorder

✅ Tip: Only delete after merge. You can always restore from history or tags if needed.

🕰️ Need to Roll Back? You Don’t Need the Branch.

🏷 Use Tags

Tags are lightweight bookmarks.

git tag -a v1.0 -m "Public beta launch"
git push origin --tags

git checkout v1.0

🔍 Use Commit Hashes

Every commit has a hash ID.

git checkout 84ae32c

💬 Use Reflog (Local Only)

Track where HEAD has been:

git reflog

Note: Reflog only works on your local machine — not GitHub or other remotes.

🚦 Merging Strategies: Squash vs. Preserve

Squash merges can clean up noisy history but lose individual commit context:

git merge --squash feature-branch

Use squash when:

You were experimenting
Your branch commits are messy or exploratory

Prefer regular merges (--no-ff) when:

Commits are meaningful and well-written
You want history for future debugging or context

🧭 Your Git Playbook as a Solo Builder

🛠️ Daily Workflow

# 1. Start a branch
git checkout -b feat/transcript-clipboard

# 2. Make focused commits
git commit -m "✅ Add clipboard copy to transcript output"

# 3. Push your work
git push origin feat/transcript-clipboard

# 4. Merge it (squash or standard)
git checkout main
git merge --squash feat/transcript-clipboard

# 5. Delete the branch
git branch -d feat/transcript-clipboard
git push origin --delete feat/transcript-clipboard

# 6. Tag a milestone
git tag -a v1.0-beta -m "Beta release with full clipboard support"
git push origin --tags

🧠 Bonus Git Moves That Will Save You Someday

Undo last commit (keep changes):
git reset --soft HEAD~1
Undo last commit (discard changes):
git reset --hard HEAD~1
Edit last commit message:
git commit --amend -m "New message"
View commit graph:
git log --oneline --graph --all
Create a patch from a commit:
git format-patch -1 <commit-hash>

🧩 Git Concepts That Trip Up Builders

.gitignore: Use it early to avoid committing secrets or dependencies.
Staging Area: Understand that git add lets you stage parts of a change.
Reset vs Revert:
- reset rewinds your local history.
- revert safely undoes changes in public/shared repos.

🏁 Final Thoughts

Git isn’t about rules. It’s about leverage.
And as a solo builder, every tool that helps you move faster without breaking things is worth mastering.

So commit often. Branch boldly. Merge mindfully. Delete mercilessly.

Your future self — and your changelog — will thank you.

Follow along @jeremygeiger for more real-time lessons from the frontlines of solo product building.
If you liked this, check out my upcoming book, Product Built: How Product Managers Became Solo Builders.