Changesets are the heart of any version control system, and making good changesets is vitally important to the maintainability of a codebase.
When creating changesets, always code (and commit) for the maintainer.
Represent one logical change
What comprises a “logical change” is up for interpretation, but only directly related changes are included. Generally, the smaller the changeset, the better.
Good Example: Adding the CSS, JS, HTML, and PHP code for a new UI button.
Bad Example: Adding the new UI button, fixing whitespacing, and tweaking copy in the footer.
Bundle related changes together
It is much easier to trace refactorings and other changes if related changes are grouped together. Rather than splitting a logical change into many separate commits, related changes should be combined.
Good Example: Refactoring code into a new plugin by moving it to a new file and including that file.
Bad Example: Refactoring code into a new plugin by putting the code removal, addition, and include into separate commits.
Make the changeset atomic
An atomic commit means that the system is always left in a consistent state after the changeset is committed. No one commit would cause the codebase to be in an invalid state. The commit is easily rolled back to a previous valid state, including all related changes, without the need to analyze the potential interdependencies of neighboring commits.
Good Example: Adding a new feature to the home page by committing the HTML / PHP changes alongside the required CSS / JS changes, so there is never an incomplete state (HTML elements without styling) in the codebase.
Bad Example: Committing the HTML changes and requisite CSS / JS separately. The first commit represents an inconsistent state, as the feature can exist in the DOM without being properly styled.
Describe a changeset properly
Accurately describing the changes is very important for all individuals who will review or maintain the code. A good commit message describes the what and why of a change.
Last updated: December 28, 2023