Best practices

Atomic commits

A commit is atomic when it's impossible to divide it further.

Commit unrelated changes separately, so that each commit is a logical unit of work. This approach makes it easier to understand the history of changes and to revert them if needed.

Bad
1a2b3c
Alex Shvets
2025-04-20 10:00
Added coupons functionality (and fixed links in email notification templates) (oh, and refactored email scheduler).
+ Store/Coupons.js
+ styles/coupons.css
M Core/Scheduler/emails.js
M Emails/layout.tpl
Good
1a2b3c
Alex Shvets
2025-04-20 10:00
Added coupons functionality.
+ Store/Coupons.js
+ styles/coupons.css
9f5110
Alex Shvets
2025-04-20 11:00
Fixed links in email notification templates.
M Emails/layout.tpl
bbc129
Alex Shvets
2025-04-20 11:15
Refactored email scheduler.
M Core/Scheduler/emails.js

Advantages

  • Easier to understand: Atomic commits are focused on a single logical change, making it easier for others (and your future self) to understand the purpose and impact of each commit.
  • Simplified debugging: When a bug is introduced, atomic commits make it easier to pinpoint the exact commit that caused the issue, as each commit is a self-contained change.
  • Improved collaboration: Atomic commits make it easier for team members to review and provide feedback on specific changes, as each commit is focused on a single task or fix.
  • Cleaner history: By keeping commits atomic, your project's history remains clean and organized, making it easier to navigate and understand the evolution of your codebase.
  • Easier rollbacks: If a specific change needs to be reverted, atomic commits allow you to do so without affecting other unrelated changes, minimizing the risk of introducing new issues.
  • Enhanced cherry-picking: Atomic commits make it easier to cherry-pick specific changes between branches, as each commit represents a self-contained unit of work.

Pitfalls

Atomic commits can backfire in a few ways if overused:

  • Over-granularity: Breaking changes down too much can lead to an excessive number of tiny commits that are hard to follow and reason about.
  • Loss of context: By focusing on small, isolated changes, the bigger picture and context of the overall feature or fix can get lost.
  • Increased overhead: Making many small commits requires more time spent on committing, pushing, and potentially opening multiple pull requests.
  • Difficulty in rollbacks: If a feature requires multiple atomic commits and a rollback is needed, it can be harder to revert cleanly.
  • Reduced readability: The full story of a change may be spread across many commits, making it harder for other developers to understand by reading the history.

The key is striking a balance — keep commits focused and digestible, but not so granular that they lose meaning and are hard to manage. Logical, self-contained commits are the goal.

© 2024-2025 GitByBit.All rights reserved.

Hi! I'm Alex, creator of GitByBit.

And this is Gitopedia—a reference that summarizes knowledge in my Git course.

Gitopedia is designed to be a personal knowledge base. When you progress through the main Git course in VS Code, you unlock all of these topics, one by one, bit by bit. This gives you time to digest the information and gradually build the mental model of Git. Here's an example of how it works:

Learning directly in VS Code lets you practice Git exactly as you would in real life, doing real jobs, writing real code. In addition, the course has access to your actual terminal, so it can point out mistakes, suggest workarounds, etc.

The course is FREE, there are no Ads or other bullshit. There are optional premium add-ons you can purchase, mainly to support my work (regrettably, I have to eat every day), but that's totally up to you.

Learn Git in VS Code