Your Git Tree Looks Like a Crime Scene: How to Write Commits That Don’t Suck

Dometrain — Thu, 28 May 2026 13:52:23 +0000

It’s Friday at 4:45 PM. You’re packing your bag, thinking about the weekend, when the team lead drops a message in Slack: “The production billing engine is throwing random database exceptions. Something broke in the last deploy. We need to find out what changed.”

You jump onto GitHub, open the main branch, and look at the commit history from the last 24 hours to find the culprit. This is what you see:

wip
fixed bug
hope this works
typo
clean up code
actually fixing it now
fuck regex

You look at the diffs. The commit labeled clean up code contains 14 changed files, two database migrations, and a completely rewritten authentication handler. The commit labeled typo actually changed a critical calculation in the payment pipeline.

You can't trace anything. You can't safely revert a single commit because they are all massive, tangled balls of unrelated changes wrapped in useless labels. You’re stuck doing a manual line-by-line code review of 400 changes while the system bleeds cash.

If this is what your Git history looks like, you aren't just writing messy commits. You are actively torturing your teammates, your future self, and your incident response team. It’s time to talk about Git hygiene.

1. Git is a Chronicle, Not a "Save Game" Button

The root cause of a garbage Git tree is a fundamental misunderstanding of what Git is for.

Many developers treat Git like the quick-save button in a video game. They write three lines of code, smash git commit -am "wip", and repeat this every ten minutes just in case their laptop explodes.

Let's clarify something: Your local branch belongs to you. The shared history belongs to the team.

It is completely fine to commit absolute garbage locally while you are figuring out a problem. Knock yourself out. But the moment you open a Pull Request to merge that code into a shared branch (main, dev, etc.), you have a responsibility to clean your room. The history should read like an organized, step-by-step story of how a feature was built—not a real-time stream of consciousness from a confused developer.

2. The Anatomy of a Commit That Doesn't Suck

A good commit message is a form of asynchronous communication. It exists to answer two questions for the person reading it three years from now: What changed? and Why did it change?

To do this effectively, the industry has a widely accepted standard called the 50/72 Rule. It’s incredibly simple, yet almost nobody follows it by default.

Plaintext
Summarize the change in 50 characters or less (Imperative mood)

More detailed explanatory text, if necessary. Wrap it to about 72 
characters. Focus on WHY the change was made, not just WHAT changed. 
Reference any relevant issue or ticket numbers at the bottom.

Fixes #402

The Rules of the Subject Line:

Use the Imperative Mood: Write your commit subject as if you are giving a command to the codebase. Use Add checkout endpoint, not Added checkout endpoint or Adding checkout endpoint.
Pro-Tip: A good trick to check this is to complete the sentence: "If applied, this commit will... [Your Subject Line]." If it makes grammatical sense, you’re doing it right.
Capitalise the first letter.
Do not end the subject line with a period. It’s a title, not a sentence.
Keep it short: Under 50 characters ensures it doesn't get truncated in GitHub or terminal logs.

The Rules of the Body:

The code tells you how something was done. The commit body should tell you why. If you had to implement a weird workaround because a third-party API has a known bug, put it in the commit body. The person debugging this code in 2029 needs to know you didn't just write that ugly code because you were lazy, you wrote it because you were constrained.

3. Your Secret Weapon: Interactive Rebasing

"But I like making tiny, messy commits while I work! It helps me track my thoughts!" Great. Keep doing that. But before you hit that "Create Pull Request" button, you need to run an Interactive Rebase to squash your messy drafts into a clean production history.

Let's say you're on a feature branch and you've made 5 messy commits. Run this in your terminal:

Bash
git rebase -i HEAD~5

This opens a text menu in your editor that looks something like this:

Plaintext
pick a1b2c3d Add initial checkout logic
pick e4f5g6h wip
pick i7j8k9l typo fix
pick m0n1o2p refactor billing service
pick q3r4s5t hope this works

This menu allows you to rewrite history before anyone else sees it. You can change pick to commands like squash (to blend a commit into the one above it) or reword (to fix a bad message).

If you update the menu to look like this:

Plaintext
pick a1b2c3d Add initial checkout logic
squash e4f5g6h wip
squash i7j8k9l typo fix
pick m0n1o2p Refactor billing service parameters
squash q3r4s5t hope this works

When you save and close, Git will magically compress those 5 messy, chaotic commits into 2 clean, logical steps. Your wip and typo fix commits disappear from history, absorbed into the main feature logic where they belong. Your Git tree goes from looking like a crime scene to a masterclass in professional software delivery.

4. Git is a Forensic Tool, Use It Like One

When you maintain high Git hygiene, the tool starts working for you. You gain access to advanced forensic commands that make debugging complex system bugs incredibly fast.

git log --oneline

Instead of scrolling through pages of text, you get a clean, high-level map of the system's evolution. If your messages are disciplined, you can spot anomalous changes in seconds.

git blame

When you find a broken line of code, git blame tells you the exact commit that introduced it. If that commit message says Fix database deadlock under high load (#204), you instantly have the context, the pull request, and the original business requirements behind that line of code. If it says wip, you have nothing.

git bisect

This is the holy grail of debugging. If you know the app worked perfectly on Monday, but it's broken today, and there are 200 commits in between, you don't have to manually check them all. git bisect uses a binary search algorithm to find the exact commit that broke the app. It checks a commit in the middle, asks you if the code is good or bad, and narrows down the search. If your commits are small and atomic, git bisect will point to a single 10-line change, and your bug is found in minutes.

5. Moving Past the Coder Mindset

It’s easy to look at things like commit formatting, interactive rebasing, and branching hygiene as "extra work." Juniors often complain that it slows them down.

But true seniority isn't about how fast you can type code into a file. It’s about how easily that code can be maintained, debugged, and understood by a team over a multi-year lifecycle. A developer who leaves a trail of unreadable commits behind them is creating a tax that the rest of the team has to pay every time there is a production incident.

Excellent development hygiene is a habit that has to be learned intentionally. Most bootcamps and standard video platforms will teach you how to run git commit -m "first commit", but they completely ignore the operational realities of working on production codebases at scale.

This is where real-world, no-nonsense engineering training makes a difference. At Dometrain, our courses focus heavily on the practices that define the top 1% of engineers. We don't just show you how to write modern C# syntax; we focus on the everyday developer habits—from clean testing to robust architectural patterns—that help you step off the mid-level plateau and confidently own a production ecosystem.

The Git Hygiene Checklist

Before you push your next branch to the remote repository, spend two minutes running through this checklist:

Run git log locally: Look at your branch history. Does it look like a cohesive story or a messy scratchpad?
Interactive Rebase: If you see wip, typo, or duplicate commits, run git rebase -i and squash them down.
Check your subject lines: Are they under 50 characters? Do they start with a capital letter? Are they written in the imperative mood (Add, Fix, Remove)?

Isolate your changes: Ensure a single commit does one thing. Don't mix formatting changes, feature development, and dependency updates into a single giant commit.

Your Git tree is a direct reflection of your engineering discipline. Stop treating it like an automated backup tool, clean up your history, and start writing commits that make your teammates want to buy you a coffee instead of tracking you down after a failed deployment.

DEV Community: Dometrain