Well, I've called it what.

The code is what I'm committing; the subject is why I'm committing it; the message is (a continuation of the subject's why and) a description of how I arrived at it, how it applies to the problem, etc.

Of course it can be phrased differently ('code is how I'm solving the problem; subject is what problem I'm solving' etc.) - I really don't think it matters much what we call them. Point is that, IMO, the subject especially and to a large extent the rest of the message should focus on the reason for the change, not re-describe the change itself, and framed in a way that's not necessarily end-user oriented but is certainly more detached from the implementation in code.

Less ambiguous than what/why/how then: code - the change; subject - the reason for it; message - the explanation of it.