Making more than one change per commit is a bad thing, but even splitting a single change into more than one commit is considered harmful. As you may already know, in some trained teams you do not simply push your code to production; first you have to pass code quality reviews, where someone else tries to understand what you did to decide if your code is good or not (that is why there are pull requests, indeed). You can be the best developer in the world, but if the person at the other end can't get a sense of your commits, your work will probably be refused.

To avoid these unpleasant situations, you have to follow a simple rule: don't do partial commits. If time's up, if you have to go to that damn meeting (programmers hate meetings) or whatever, remember that you can save your work at any moment without committing, using the git stash command. If you want to close the commit, because you want to push it to the remote branch for backup purposes, remember that Git is not a backup tool: backup your stash on another disk, put it in the cloud, or simply end your work before leaving, but don't do commits like they are episodes of a TV series.

One more time, Git is a software tool like any other, and even it can fail: don't think that by using Git or other versioning systems you don't need backup strategies - backup local and remote repositories just the same as you backup all the other important things.