>>to keep it short
>>https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
>
>I think you're confusing the inner workings of Git with the over all philosophy. Git's internal workings as a diff engine that only stores differences has no impact on how you manage your source control usage.
>
>Unlike SourceSafe or SVN, Git only stores changes. But the changes you store are up to you to decide and there's nothing that suggests that 'saving everything' is the way to go. The reason to break out files is not for Git benefit, it's for me to provide a reasonably trackable audit trail of changes that aren't just a boatload of unrelated incidentally changed files, but rather those things that are relevant for a given fix or new feature. Occasionally then I need an extra commit for 'project maintenance' to update incidental files that don't fit into feature fixes.

It's somewhere around the page I've linked. Anyway, it's philosophical, nothing more. As long as it works, all is fine. :)
To me a commit should hold all related changes to a task. Since before the task all is commited anyway, all change must by the task - so I do: git add .; git commit
commit message tells the task, that's it. Possibly multi times over the work on a task. Possibly branched for progress on different tasks. The trail is there by git anyway.