Then you'd have to explain to non-technical clients what commits are, and then it comes to the problem of big and small commits. Some enjoys "commit early, commit often", other enjoys squashing commits into a big one. This solution reminds me of invoicing per line of code.

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.

This just doesn't make any sense to me as a developer, I can't imagine what a client thinks of it, incredibly opaque.

And you seriously charge €40 to move a button to the left or change a few hex codes? You must have some desperate clients.

Moving a button or changing color was to exemplify for a hypothetical client what a commit is, if said client was “non-technical”.

Seriously, what is with the sudden down-voting of all my comments?