“Everyone thinks they understand Git… until the day they run git push -fto main and production goes down.”
- every senior dev, ever.

Another Day, Another TODO

Another day at office.
Another list of TODOs.
Another bug fix at the top.

Read issues. Went through lots of documentation, messed up AI suggestions and Stack Overflow rabbit holes. Finally, figured out a fix that actually works.

Time to strike off TODO#1:

git add .
git commit -m "fix button"
git push origin main

And just like that—your fix flies into the repo.

“fix button” is not a commit message

No context.
No reference.
No breadcrumbs for your team.

Tomorrow, someone else will spend hours decoding what “fix button” means. Again.
More meetings, more confusion, more lost time.
Deadline delayed. Cost inflated. Team morale: low.

All because someone (you?) didn’t take 10 extra minutes to write a proper commit, link a ticket, or open a clean PR.
But hey—we’re developers, right?

Why should we waste our brilliant minds writing documentation?
We’re here to code. Build features. Ship fast.
Not explain ourselves like some sort of glorified tech scribe… right?

But is that really what we are?
Just freelancers? Solo programmers?

Or are we part of something bigger?
A team. A culture. A community.

Isn’t it our responsibility to help fellow developers understand what we did?
To document the algorithms we chose,
the trade-offs we made,
the thought process behind that “quick” fix?

Isn’t that how we grow—not just as coders, but as collaborators?
Because at the end of the day, this isn’t just your code.
It’s our codebase.

But here’s the catch—most of us never get taught how to work like that.
We copy-paste commands, follow Git tutorial, memorize enough to survive.

We think we know Git…
Until the day it turns on us.
Until a git reset —hard wipes out hours of work.
Until a git push -f crashes production.
Until we’re debugging someone else’s commit message from six months ago that says… “final fix fr.”

That’s when it hits us—
We never really knew Git.
We just knew the commands.

But teams who do know Git—
They don’t treat it like a magic spellbook.
They treat it like a discipline.

They’ve been burned before.
They’ve taken prod down, lost hours of work, debugged “final_final_v3_fixed” commits.

And so, they follow rules.
Not because they’re strict.
But because they’re scared.

Git Rules Teams Follow (Because They’ve Been Burned)

Stop naming branches like a college assignment

We’ve had new-ui-final2, stuff-working-proper, urgent-bug-maybe-fixed.

Nobody knows what’s going on
You might as well name it chaos-monkey.

Instead
feature/user-onboarding-modal,
fix/payment-webhook-race-condition,
hotfix/login-rate-limit-bypass

Prefix it. Standardize it. Your future self will thank you at 3AM.

Your commit message is not your secret

We’ve all written:
git commit -m "changes"

Next week: no one remembers what changed.
Next month: you don’t either.
And in prod: it definitely doesn’t work now.

Instead, write what you did and why.
Even a simple:
git commit -m "feat(auth): add JWT-based session tokens",
git commit -m “fix: logout button not working on mobile (Safari event bug)”
goes a long way.

Not just me yelling into the void—Conventional Commits explains why this works across teams and tools.

No PR? No mercy.

We’ve merged directly into main.
Hell, we’ve deployed unreviewed code.
It always ends the same.
“Why did this break?”
And nobody knows.

Now, it’s simple:

• PRs or nothing.

• Link a ticket.

• Ask for a review.

• Add a 2-line context.

Takes 10 mins now. Saves 10 hours later.

GitHub’s PR best practices shows how to keep PRs useful, not painful.

git push -f Is Not an Undo Button

The first time I ran git push -f on a shared branch,
my teammate messaged:
“Hey… uh… where’s my work?”

Spoiler: Gone. Buried in reflog hell.

Now we use git rebase -i locally.
Clean it up before pushing.
And never force push shared branches unless everyone’s aware and ready.

This Git Tower article explains when force pushing is actually okay—and when it’s a bad life choice.

Rebase vs Merge — Know When to Use What

• Rebase: your own branch → keep history clean

• Merge: shared branches → preserve the timeline

Rebasing is like editing your diary. Merging is like adding to a journal. Use with intent.

Confused? Same.
But this side-by-side visual from Atlassian’s Git guide made it click for me.

Your CI Should Slap Bad Git Practices

Configure it to:

• Block direct pushes to main

• Enforce PR reviews

• Run tests, lint, build

CI isn’t just for deployment. It’s your safety net.

Squash Commits Before Merging

No one wants to read:

commit 1: trying stuff  
commit 2: lol  
commit 3: maybe this works  
commit 4: fix typo  
commit 5: fix fix

Squash to tell one clean story per feature.

The Git Tower squash merge guide walks through it like butter.

Use Tags. Version Like a Pro

v1.2.0, v2.0.0-beta, v3.1.1-rc
Helps with changelogs, rollbacks, and rollback therapy.

.gitignore Is Not Optional

If I see your node_modules/ committed, I’m calling Git police.
Use .gitignore like your job depends on it (it does).

Debug With Git Tools (Not Slack Messages)

• git log → trace history

• git bisect → find when the bug started

• git reflog → undo almost anything

• git stash -p → stash part of your changes

Git is a time machine. Use it like Doc Brown would.

Real “Wish I Knew Git” Moments

Final Thoughts: Git Is Not Just A Tool

Git is:

• A collaboration system

• A traceability record

• A source of truth

• And when abused—a source of pain

So stop treating Git like just another terminal command.
Learn it like your team’s speed, sanity, and sleep depend on it.
Because they do.

---

Poll: What’s the worst Git mistake you ever made?

Drop it in the comments. I’ll start:

Rebased staging into prod on a Friday. Never again.