It's not hard. I use git add ., git commit -m "asdfghj", git push as my save. Exactly like I press Cmd+S in Photoshop all the time. So naturally I end up with a ridiculous amount of commits.
A thousand times this, I use `git log` as a debugging and learning tool, if I can find the exact commit that introduced a change that I don't really understand why or how was done I resort to looking into git's history to figure it out.
I hate when developers don't put an effort to tell the story of "why" you are doing what you did. The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that.
I treat git's history as a breadcrumb trail, I leave as many breadcrumbs as I can on my commits so others can find the trail later on: JIRA ticket reference, background of the change, why a refactoring is being done, what I found during the refactoring that made it end with a strange design, why the documentation needed to be edited, etc. Whatever I can think that would make my life easier in 1-2 years time if I ever had to read `git log` I try to leave for my future colleagues...
Exactly. But I have noticed for some people this seems just really hard, don't know why exactly. Even after repeating and explaining the same thing (git commits, just like comments in code, should explain why, not what, the what can be inferred from the code and if not the code is usually not very good) I see people struggling with coming up with an acceptable explanation in full sentences of why a change was made.
git commit --amend --allow-empty
[1] To be precise, it allows to create a commit that has the same tree as the parent commit.
https://git-scm.com/docs/git-commit#Documentation/git-commit...