Naturally if your commits are not fine grained, as I thought most agree is the recommended style, then this scheme would not be in your favor.

As for explaining it to the client, I’d probably just call a commit a “feature”, but something like “move button to the left” or “make it darker” is also a feature if the code is already written, and “making the code nicer” (to ease future maintenance) is a feature as well (and if he thinks this is not worth paying for, you can hold back on the refactoring, but when he wants you to extend the project beyond the initial goals, you can then point to him opting out on “clean code”, so the rate for the extensions will be set higher due to the less flexible code base).

Anyway, if you do disciplined fine grained commits, try look at some of your past projects and see how many commits you did and what the rate per commit would be given your estimated value of the work that went into the project — I found it surprisingly consistent.