Prefer Atomic Commits

Here’s a follow on from Atomic and Minimal.

Atomic commits are the Single Responsibility Principle for changes. The notion that a change should consist of a single atomic element.

Keeping changes limited to a single notion provides the following benefits:

  1. Code review is easier.
  2. When necessary, reverting is easier.
  3. Helps build a practice of shipping smaller changes more often.

This doesn’t mean changes need to be small. Consider atoms. They may be small, such as Hydrogen, or quite large, for example, Plutonium. The key is that each atom expresses all the characteristics of an element. Each change should likewise express some core difference between what is, and what will be.

In practical terms, here are some examples of non-atomic changes:

  • Mixing changes to more than one feature.
  • Mixing formating or linting changes with changes related to execution.
  • Adding or deleting code unrelated to the purpose of the change.

Here’s a really practical example when dealing with maintenance on a large Rails code base.

Updating gems

Running bundle update is a great way to ship a breaking change. Especially when there are dozens of gems needing updating, including some which are in critical path.

Using bundler for Ruby programming allows grouping like gems:

group :test do
  gem 'rspec'
  gem 'simplecov'
end

Consider the :test group as atomic as it won’t break production, and update in a single change: bundle update --group=test.

Preferring atomic commits isn’t a law. Nobody is going to jail for jumbling up changes with a mish-mash of different things. And the computer doesn’t care. However, it’s a good way to help discipline thinking, and the commit log will be more legible as a result.