Before You Commit: The Developer Checklist That Can Save You From Yourself

git add .

git commit -m "changes"

git push

Three commands.

Sometimes, three seconds.

And sometimes, enough to introduce a bug, expose a secret, break the build, or make your teammates wonder what exactly you were thinking.

We often treat committing and pushing code as a routine part of development. But a commit is more than saving your work in Git.

It is a checkpoint.

Before your code leaves your machine, there are a few things worth asking.

1. Is the code actually ready?

Start with the obvious things.

Remove the console.log.

Remove the temporary print().

Delete the breakpoint.

Clean up the TODO you added just to get through debugging.

Temporary code has a strange habit of becoming permanent.

Then check something more serious:

Did you accidentally include a secret?

API keys, passwords, tokens, .env files, private certificates—these are not things you want appearing in a Git repository.

One careless git add . can turn a five-second mistake into a security incident.

Then run your formatter and linter.

Build the application.

Run the tests.

Don't assume that because the code "looks right," it works.

A small checklist before committing can prevent a much larger problem later.

2. Your commit should tell a story

A commit should have a purpose.

If someone opens your Git history six months from now, they should have some idea what changed and why.

Compare:

fix stuff

with:

fix(auth): validate expired access tokens

The second one communicates something useful.

Good commits make collaboration easier, debugging easier, code reviews easier, and even future-you happier.

Try to keep commits focused.

A feature commit shouldn't also contain unrelated formatting changes, a random refactor, and modifications to three configuration files you forgot about.

One commit, one clear purpose.

Your Git history is part of your engineering documentation.

Treat it that way.

3. Before pushing, look around

One of the easiest mistakes to make is pushing code without checking what happened upstream.

Someone else may have merged changes while you were working.

Your branch may be behind.

A dependency may have changed.

Another developer may have modified the exact code you touched.

So before pushing, ask:

Am I working against the latest version of the branch?

Fetch and integrate the latest changes when appropriate.

If there are conflicts, resolve them locally.

And then run your tests again.

Why again?

Because resolving a conflict can change behavior.

Your code may have passed tests before the merge and fail afterward.

The goal isn't simply:

"My tests passed."

The goal is:

"My tests passed after integrating the changes I'm actually going to push."

That's a much stronger statement.

4. Check where you're pushing

This sounds ridiculous until it isn't.

You think you're on:

feature/payment-validation

But you're actually on:

main

And suddenly:

git push

has a very different meaning.

Before pushing, check your branch.

Know where you are.

Know where you're going.

And know whether your team even allows direct pushes to that branch.

A simple git branch can prevent an extremely uncomfortable conversation.

5. Don't forget the documentation

Code changes often change more than code.

Maybe you introduced a new environment variable.

Maybe you changed an API contract.

Maybe the application now requires a new service.

Maybe the setup process changed.

Maybe a developer pulling the repository tomorrow will need one additional step to get the application running.

If the behavior changed, ask yourself:

Does the documentation still describe reality?

Update the README, API documentation, setup instructions, or internal guides when necessary.

Outdated documentation is another form of technical debt.

The checklist is not bureaucracy

Developers sometimes see checklists as unnecessary process.

"I know what I'm doing."

"I've been coding for years."

"I don't need a checklist."

Maybe you don't.

But experienced engineers make mistakes too.

The purpose of a checklist isn't to remind you how to write code.

It's to protect you from the small things that are easy to forget when you're tired, rushing, distracted, or switching between tasks.

Pilots use checklists.

Surgeons use checklists.

Engineers use checklists.

Not because they are incapable of doing their jobs.

Because human memory is unreliable.

A commit should be a confidence checkpoint

Before you commit:

Is the code clean?

Are the tests passing?

Are there any secrets or temporary files?

Does the build work?

Before you push:

Am I up to date?

Did I resolve conflicts correctly?

Did I test after resolving them?

Am I pushing to the right branch?

Does the documentation still make sense?

These questions take minutes.

Recovering from a leaked credential, broken production build, or bad merge can take hours—or days.

The goal isn't to make development slower.

It's to avoid turning a simple git push into an incident.

Because writing code is only part of the job.

Knowing when that code is ready to leave your machine is part of being an engineer too.