There are two competing interests, and the author suggests cleaning up after so that you can satisfy both.
The first interest is what you said, for every commit to build.
The second interest is to help prevent loss during development. If I am working on something and need to finish for the day, but haven't yet got the code to a working state, I want to be able to commit and push my code in case something happens to my laptop.
Also, sometimes I am making a series of big changes, but I need to make them all for the code to work. I want to have checkpoint along the way, in case I need to undo something (or even just see what I have changed since the checkpoint!) committing WIP code that doesn't build lets you do that.
We usually solve this problem with squash merges, so every commit on the main branch is the full working feature, but there are downsides to that technique.
The first interest is what you said, for every commit to build.
The second interest is to help prevent loss during development. If I am working on something and need to finish for the day, but haven't yet got the code to a working state, I want to be able to commit and push my code in case something happens to my laptop.
Also, sometimes I am making a series of big changes, but I need to make them all for the code to work. I want to have checkpoint along the way, in case I need to undo something (or even just see what I have changed since the checkpoint!) committing WIP code that doesn't build lets you do that.
We usually solve this problem with squash merges, so every commit on the main branch is the full working feature, but there are downsides to that technique.