I don't know what the official definition is but to me an atomic commit is a commit that is focused on one context and one context only. By context I mean a single topic: a feature, bug fix, refactor, upgrade, task...
In a monolithic commit everything is committed in one go. A tightly coupled, tangled, or a spaghetti commit. The larger the commit, the more brittle and error prone it becomes because it becomes harder to understand, read, review and revert.
They are easier to:
track - I know where they are in the history.
git log --onelineshows me all commits.
git log --grep <pattern>lets me find a commit based on a partial message.
git log <commit>will jump to that commit and show previous commits.
understand - I document each change with a commit message and elaborate with an explanation if I need to.
read - it's a change focused on a single context which makes it smaller, simpler and easier to read the patch
git show <commit>or
git log <commit> -p
review - as it is a small, focused, documented change, a reviewer should easily be able to follow the code changes and keep their sanity.
revert - reverting
git revert <commit>an atomic commit will not revert unrelated changes like a monolithic commit would.
- Work on one thing
- Keep my changes as small as possible
- Commit often
- Be vigilant that tests pass
- Use an interactive rebase
rebase -ior interactive mode
git add -iwhen I mess up the order of my commits or litter my working directory with different features
I don't always get it right, sometimes things get messy and I end up with more than I can chew because I didn't follow my guidelines. I aim to stick to them as best as I possibly can.
I want to pragmatically craft relevant changes for a better history, cognitive load and an easier means to rollback changes.