>I don't get the point of commit messages, I mean I understand them in theory but in practice they seem to lose their effectiveness.
The point is that they work as a brief overview for other developers. It explains what you just did so that others can easily review your code without problems.
>What happens to me irl is that usually by the time I'm ready to make a commit I'm burned out and too tired to make some beautiful commit message recapping everything I've done.
Your commits are likely too large. Commits are small, incremental changes. Just make sure that your commits compile before you commit them, or rebase squash two commits if you have to make a small fix to make it compile if you've already committed.
>It's like muscle failure but with your brain where I hit my max reps and I just can't think anymore by the time the commit comes.
That should be the push to remote, not the commit.
>to counteract this I keep a production log text file in my projects where I document my changes and thoughts WHILE I'm making the changes.
That's exactly what a commit message SHOULD be.
>My production log entries are dated and have notes about what to work on next time etc.
In fact, I'd argue they're superior. Not only are commit messages dated, but they have the commit's hash and the associated diff right along with it.
>I still try to make a general commit message about what was changed but I rely on my production log for notes not my commit messages.
My suggestion is: commit more often. When you write a new function (or a small amount of, if they're small), you might want to commit with a message along the lines of:
Early steps towards functionality x
This implements function foo() as an early step towards functionality x
and takes arguments x, y and z. It does [description of functionality]
and returns [description of return values and their conditions]
1/2