My average commit is 15 lines. Here's why.

Big Commits Are a Code Smell

When I see a 500-line commit, I don't think "productive." I think "what's hiding in there?"

Big commits are:

  • Hard to review. Reviewers skim. Important bugs slip through.
  • Hard to revert. One bad change means unwinding everything.
  • Hard to understand. Three months later, you won't remember what "fix everything" meant.

They're also a sign of unclear thinking. If you can't explain your change in one sentence, you're probably doing too many things at once.

What Small Commits Look Like

A good commit does one thing. Examples:

  • "Add user validation function"
  • "Fix off-by-one error in pagination"
  • "Rename config to settings for clarity"
  • "Remove unused import"

Each one is a complete thought. Each one could be reverted independently. Each one tells part of a story.

When I'm working on a feature, my commit history looks like this:

Add empty handler for /api/tasks
Implement task creation logic
Add input validation
Add tests for task creation
Update API docs

Not this:

Add task API with validation and tests and docs

Why This Makes You Faster

It feels slower. It's not.

Reviews go faster. A 20-line PR gets approved in minutes. A 500-line PR sits for days while reviewers find time to "really dig in."

Debugging goes faster. git bisect finds the problem in seconds when each commit is atomic. In a monolith commit, you're back to printf debugging.

Collaboration goes faster. Small commits mean small merge conflicts. You can rebase without fear.

Your thinking goes faster. Breaking work into commits forces you to think in steps. That clarity shows up in your code.

How to Break Work Down

Before you start coding, ask: "What are the steps?"

Write them down. Each step is a commit.

If you're mid-way through a big change and realize you should commit, do it anyway. git add -p lets you stage just the pieces that belong together.

If you're not sure whether to commit, commit. You can always squash later. You can never unsquash.

The Rule

One commit, one thing.

If your commit message has "and" in it, it's probably two commits.

Small commits aren't about being pedantic. They're about being kindβ€”to reviewers, to future you, and to anyone who has to debug your code at 3am.

Ship small. Ship often. Your git log is documentation too.

React to this post: