Nobody quits a job over Git. But Git quietly steals hours from every team that doesn't respect it.
The lost afternoon untangling a merge. The "wait, which commit broke this?" archaeology. The PR so big nobody actually reviews it, so the bug ships. None of it is dramatic. All of it adds up.
A couple of years ago my team made seven small changes to how we use Git. No new tools. No process theater. Just habits. We got hours back every week, and I want to give you the exact list.
The seven habits, in order of impact:
git bisect instead of guessing.That's it. Now the why, because the why is what makes them stick.
The most expensive Git habit is the giant commit. "Add feature" with 40 changed files is a commit you can't reason about, can't revert cleanly, and can't review.
Small commits are reversible thoughts. When something breaks, you want to roll back one idea, not a day's work. I aim for a commit that does exactly one thing and could be described without the word "and."
The rule I give new hires: if your commit message needs the word "and," it's probably two commits.
Six months from now, someone runs git blame on a confusing line and finds your message. If it says "fix stuff," you've failed that person. That person is often you.
A good message answers why, not what. The diff already shows what changed. It can't show why. This habit of writing for the next reader is exactly the kind of unglamorous discipline I came to see as the real mark of a senior developer — the work that never shows up as a commit but quietly carries the team.
bad: fix bug
good: fix race condition in cache eviction
The eviction timer fired before the write completed, so reads
occasionally hit a half-written entry. Add a write lock around
the eviction path.
The first line is a summary under ~50 characters. A blank line. Then the context. This takes thirty extra seconds and saves the next person thirty minutes.
Even a one-line fix gets its own branch. This sounds like overkill until you realize what it buys you: your main branch is always deployable, your work is always isolated, and you can context-switch without panic.
Cheap branches are the whole point of Git. Use them like they're free, because they are.
A clean main branch isn't a nice-to-have. It's the thing that lets you ship on a Friday without sweating.
This is the habit that removed the most pain. When you git pull the normal way on a feature branch, you create a merge commit every time, and your history turns into spaghetti.
Set this once and forget it:
git config --global pull.rebase true
Now pulling replays your commits on top of the latest changes, keeping history linear and readable. A linear history makes git bisect, git log, and code review dramatically easier. One config line. Hours saved.
The one caveat: never rebase a branch other people are actively building on. Rebase your own work, merge shared work.
A 1,000-line PR gets a "LGTM" and a rubber stamp. A 150-line PR gets a real review. The math of attention is brutal: reviewer focus drops off a cliff somewhere around a few hundred lines, a pattern echoed in GitHub's own Octoverse research on how healthy teams keep changes small and reviewable. The same locating-not-flailing instinct that powers a tight PR is what turned my debugging into a method instead of a guess.
Small PRs ship faster, catch more bugs, and don't sit rotting for three days waiting on someone to find a free hour. If a feature is big, break it into a stack of small PRs that each stand alone.
My loose rule: if a teammate can't review it in fifteen minutes, it's too big.
This is the trick most developers know exists and never use, and it's pure magic.
A bug appeared somewhere in the last 200 commits and you have no idea where. Instead of guessing, you let Git binary-search the history:
git bisect start
git bisect bad # current commit is broken
git bisect good v2.3.0 # this old version was fine
# git checks out a middle commit; you test and tell it:
git bisect good # or: git bisect bad
# repeat a handful of times until it names the exact commit
git bisect reset
It finds the breaking commit in about log2(n) steps. Two hundred commits becomes roughly eight tests. I've watched this turn a half-day hunt into a ten-minute one.
Merged branches are clutter, and clutter is friction. A repo with 80 stale branches is a repo where nobody can find anything.
After a branch is merged, delete it. Periodically prune the dead ones:
git branch --merged main | grep -v main | xargs git branch -d
git remote prune origin
A tidy branch list is a tiny thing that keeps the whole team oriented. It also has a quieter benefit: when a teammate opens the branch list and sees only active work, they trust the repo. When they see 80 stale branches, they stop trusting that anything is where it should be, and they start asking you instead of looking. Clutter doesn't just slow the tools — it erodes the team's confidence that the repo reflects reality. A clean branch list is a small, ongoing promise that what you see is what's actually happening.
| Habit | Time to adopt | Pain it removes |
|---|---|---|
| Small commits | Instant | Painful reverts, unreviewable diffs |
| Good messages | 30 sec each | Future archaeology |
| Branch everything | Instant | Broken main branch |
| Pull with rebase | One config line | Spaghetti history |
| Small PRs | Per PR | Rubber-stamp reviews |
| git bisect | Learn once | Hours of bug hunting |
| Branch cleanup | 1 min weekly | Repo clutter |
This one didn't make the list of seven because it's less about Git mechanics and more about humans, but it might save the most time of all.
A pull request isn't just a code change. It's a message to a reviewer who has limited attention and a dozen other things to do. A PR that opens with "what this does, why, and what to look at" gets reviewed fast and well. A PR that's just a diff gets a tired skim and a rubber stamp.
I write every PR description in three short parts now. What changed, in one sentence. Why it changed, in one or two. And what to focus on — the risky bit, the decision I'm unsure about, the file that matters most. That last part is the gift: you're doing the reviewer's triage for them, pointing their scarce attention at exactly the place it's worth spending.
The payoff compounds in two directions. Reviewers catch more bugs because you've aimed them at the dangerous code instead of letting them spread attention evenly across boilerplate. And six months later, when someone's reading the merged PR to understand why a thing exists, your description is the documentation they need. The git history stops being a wall of diffs and becomes a readable account of how the system got the way it is. That's worth far more than the two minutes it costs, and like every habit on this list, it's free.
If you want more of these small, compounding habits that quietly buy back hours, it's the kind of thing I keep digging into — pick one this week and let it prove itself before you add the next.
Q: Isn't rebasing dangerous? Only on branches other people share. Rebase your own feature branches freely; merge shared branches. The "never rewrite public history" rule is the whole safety net.
Q: How small should a commit really be? Small enough to describe in one sentence without "and." That's a better test than any line count.
Q: Do these matter for solo projects? Even more, honestly. Future-you is a different person with no memory of today. Good Git habits are a gift you mail forward.
Q: What if my team resists? Don't mandate seven things at once. Introduce one, let people feel the payoff, then add the next. Habits spread by example, not decree.
None of these habits is clever. That's exactly why they work.
Git pain is rarely one big disaster — it's a thousand small frictions, every week, forever. Remove the friction and the hours come back on their own.
Pick one habit from this list and start it tomorrow. My bet is rebase-on-pull or git bisect will pay for itself before the week is out. Which one are you starting with?
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!