When to make a Git Commit

The post argues for two times to make a commit: when a unit of work is complete and when a change may need to be undone later. It says each commit should contain only that set of changes, and changes you may want to revert should be kept in their own commit so they are easy to find and use with git revert.

It rejects defining a unit of work by time or by type of change, such as new files versus modified files, code versus HTML, or client versus API. Instead, it treats feature as the better measure because it gives more context and helps commits tell a story while still leaving room to decide the size of the unit.

Reading notes

#

• Commit when a unit of work is complete.
• Commit when a change may need to be undone later.
• Keep only one set of changes in each commit.
• Put changes you may want to revert in their own commit so they are easy to find with git revert.
• Do not define a unit of work by time.
• Do not define a unit of work by change type, such as file type, code layer, or location.
• Define a unit of work by feature because it gives more context and helps the history tell a story.
• A feature can vary in size, so the unit still needs judgment.