Atomic commit rule of thumb
Your commit might not be atomic if your commit message title needs an “and” in it, or if you find yourself describing other
effects of the commit, rather than “why,” in the extended commit message.
How to create atomic git commits
An “atomic commit” encapsulates a set of changes that serve a single discrete purpose, and is as minimally dependent on other commits as possible.
The primary benefit of organizing your work into atomic commits is that you’ll be able to organize them freely, reorder them, squash them together as needed, etc. It will also be much easier to read through commit messages and understand exactly what each commit does.
Often I find my git repo has pending changes related to a handful of different features at a time. If you’re having trouble creating atomic commits, you can use the following techiques/tools to improve your commit fu:
- Selectively
git add,git reset, orgit checkoutwith the-pflag - Use a WIP commit(s) to put some changes aside while you work
Examples of atomic commits
An atomic commit could:
- Fix a specific bug
- Update a framework dependency
- Remove a bunch of unused or orphaned code
- Add a new feature for certain users of the application
Examples of non-atomic commits
Non-atomic commits might do the following types of things. Avoid commits like these:
| A commit that… | Should instead be… |
|---|---|
| Fixes multiple bugs | Separate commits, one for each bugfix |
| Removes some unused code and adds a new feature for application users | Separate commits, one for removing unused code and one for adding a feature |
| Adds two new features for application users | Separate commits, one for each new feature |
| Removes logging of certain metrics and change some UI colors | A commit to remove some logging and a commit to change some UI color |
| Adds a feature and modifies UI colors | A commit to add a feature and a commit to modify UI colors |