7 Git Habits That'll Save Future You From Present You
Nobody teaches you these. You just get burned once, and then you do it forever. Here are seven Git habits that look like overkill right up until the moment they're not. "fix bug" tells you nothing six months from now. Compare: fix bug to: fix: prevent double-charge on retry when Stripe webhook arrives twice Webhook retries were creating duplicate charge records because we weren't checking for an existing idempotency key before processing. The second one means git log becomes an actual debugging
Nobody teaches you these. You just get burned once, and then you do it forever.
Here are seven Git habits that look like overkill right up until the moment they're not.
1. Write commit messages for the person debugging at 2am (it's you)
"fix bug" tells you nothing six months from now. Compare:
fix bug
Enter fullscreen mode Exit fullscreen mode
to:
fix: prevent double-charge on retry when Stripe webhook arrives twice
Webhook retries were creating duplicate charge records because we
weren't checking for an existing idempotency key before processing.
Enter fullscreen mode Exit fullscreen mode
The second one means git log becomes an actual debugging tool instead of a wall of noise. When production breaks at 2am, you want to git blame a line and immediately understand why it's there — not have to go find the person who wrote it and ask.
2. Commit early, commit often, clean up later
A lot of people avoid committing until a feature is "done" because they don't want messy history. This backfires — you lose the ability to git bisect your way to a bug, and if something breaks mid-feature, you've got no safe point to roll back to.
The fix: commit constantly while you work, then squash before merging if you actually care about a clean history:
git rebase -i HEAD~5
Enter fullscreen mode Exit fullscreen mode
Messy while you work, clean when it matters (the shared history). Best of both.
3. Never trust git push --force on a shared branch
--force overwrites whatever's on the remote with your local branch, full stop — including anyone else's commits that got pushed in the meantime. On a solo feature branch, fine. On anything shared, it's a landmine.
The safer version:
git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode
This refuses to push if the remote has commits you haven't seen yet. It fails loudly instead of silently deleting someone's work. Make this your default and you'll never have to have that conversation with a teammate.
4. Use git stash before you regret not using it
You're mid-fix, someone pings you about an urgent bug on another branch, and your working directory is a mess. Don't commit garbage just to switch branches:
git stash
git checkout other-branch
# ...fix the urgent thing...
git checkout original-branch
git stash pop
Enter fullscreen mode Exit fullscreen mode
Your half-finished work waits exactly where you left it. This one's simple but genuinely underused — a lot of developers just don't reach for it out of habit.
5. Tag your releases, even on side projects
git tag -a v1.2.0 -m "Add CSV export"
git push origin v1.2.0
Enter fullscreen mode Exit fullscreen mode
Six months from now when something breaks and you need to know exactly what shipped in which version, tags turn "when did we change this" from an archaeology project into one command: git log v1.1.0..v1.2.0.
6. Keep a .gitignore before your first commit, not after
Committing a node_modules folder or a .env file once and then trying to remove it later is its own special kind of pain — it stays in history forever unless you rewrite it, and rewriting shared history is a bad time for everyone. Two minutes with a template at the start saves hours later:
curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/main/Node.gitignore
Enter fullscreen mode Exit fullscreen mode
7. Read the diff before you commit, every time
git diff --staged
Enter fullscreen mode Exit fullscreen mode
Thirty seconds, every commit, no exceptions. This is the single habit that catches the most embarrassing mistakes — a stray console.log, a hardcoded API key, a debug line that was supposed to be temporary three days ago. Cheaper to catch it here than in code review, and much cheaper than catching it in production.
None of these are clever. They're all boring, cheap, and easy to skip — which is exactly why they're worth turning into muscle memory before the day you need them.
What's the Git habit that saved you the hard way? Curious what everyone else has learned from getting burned.
