My personal approach to a git commit is that every commit should include a unit of change, in its completness.
When I develop, I usually focus on such units. But sometimes, my attention strays someplace else and I work for a while on a different unit. This is probably not optimal, but I have learned to commit carefully (
git add --interactive is a good friend of mine).
However, it could happen that I forget to selectively stage my changes and instead commit the whole file, believing that all the changes I see in the diff are indeed related to the same unit, even though there might be a change or two completely unrelated.
Is this dangerous? Should I make effort to amend the commit so that it only includes the intended changes? My primary concern is that whoever else looks at the history will see the change and will probably scratch their heads for several minutes before realising it is most likely a mistake. Worse still, I can imagine that the change will even look related and the programmer might not recognise the error.
The problem is, since I have already pushed, I cannot safely rewrite the server's history, so I would probably have to first revert the commit, split it properly and commit again. Alternatively, I could just amend the commit with a better commit message, but I would have to be really really fast since it also requires rewriting history. As a last resort, I might simply commit the unit I was working on as next, leaving a note that there is a related change in previous commit (but this feels wrong).
I understand that in a multi-developer setups with proper code-review workflow this would likely not happen. I also understand that if I am the sole developer on a project, then rewriting history is the best solution for this.