26. Commit Often

"Commit Often" sounds like one of those incredibly simple tiles of wisdom - but in practice, it is surprisingly underused.

Yet it is one of the most powerful habits you can develop as a developer. Not just for yourself, but for your team, your codebase, and your future self who has to figure out, three months from now, what on earth happened in this part of the code. 😅

Why you should commit more often

Many developers commit too little and too late. They work for hours (or even days), and then create one giant commit with a message like "Fix stuff" or "WIP". It may feel efficient, but in reality it is the exact opposite.

When you commit often:

• You make smaller, more digestible steps
• Code reviews become much easier
• Merge conflicts are easier to resolve
• You can roll back safely

Commit Often becomes even more important with AI 🤖

More and more developers are using AI to generate code: entire functions, components, tests, or even full modules. That is great, but AI also makes mistakes. And maybe even more important: AI is (for now) still worse at debugging than you are.

AI is great at generating new code, but it often does not fully understand:

• The complete context of your project
• All edge cases
• The history of previous decisions

The risk: you accept an AI suggestion, let it refactor a few times, copy-paste a couple of extra snippets, and 10 minutes later:

• Something else suddenly stops working
• Subtle bugs creep in
• You no longer know exactly what changed

If you are not committing regularly, it becomes a nightmare to figure out where things went wrong.

That is why you should commit before you let AI make big changes.

A few practical tips:

• Commit before you let AI touch large parts of your code. That way, you always have a clean "pre-AI" version to fall back to.
• Do not let AI "fix ten things at once" without a checkpoint. Large, combined changes are much harder to debug.
• Use your commit history as a safety net. Large, combined changes are much harder to debug.

AI is a fantastic assistant – but you are still responsible for quality. And a good commit history is one of the strongest tools you have to protect that quality. 💪

What does "Commit Often" look like in practice?

Some guidelines I like to use:

• Commit whenever something is "done" in a small, logical step. For example: Set up basic UI skeleton → commit. Get the API integration working → commit. Add validation → commit. Finish styling → commit
• Every commit should have a clear purpose. If you cannot clearly describe your commit message, the commit is probably too big or too messy.
• Separation of concerns… also in commits. Do not mix refactors, bugfixes, and new features in a single commit. Small bugfix? Own commit. Minor refactor? Own commit. New feature? Own commit.

"But my code isn't perfect yet…"

It does not have to be. You do not need to wait with committing until everything is pixel-perfect. A commit is not a final product, it is a step in the timeline of your work.

Important difference:

• Do not push everything straight to main
• But do commit locally, and do it often

Use feature branches, work in small steps, and push regularly to your branch. That gives you a clean history without shipping half-finished work to production.

Your future self will thank you 🙏

Imagine yourself a few months from now, running git blame or git log trying to figure out:

• Where was this bug introduced?
• Why was this decision made?
• What exactly changed here?

If at that moment you see small, focused commits with clear messages – especially around AI-generated changes – you will be incredibly grateful to your past self. If all you see is "WIP" and "fix"… not so much.

And you?

How do you handle commits today?

• Are you already committing early and often?
• Or do you still catch yourself "just quickly pushing through" and then doing one big WIP commit at the end?
• And how do you combine AI-generated code with your Git workflow? Do you commit first, or let AI happily rewrite your entire file?

Worth pausing on – I am curious how you and your team approach this.

How I can help

Want to help your team:

• Use Git and branching in a more professional, predictable way?
• Build a healthy workflow around AI (Copilot / ChatGPT / Claude / Gemini) and code quality?
• Improve reviews, quality, and speed without creating chaos?

I help teams level up their frontend and their workflow – including clear standards for commits, reviews, and AI usage.

Feel free to send me a message if you would like to spar about that.