In my opinion, `git add -p` should be the default, and a `-a` or alike to forcibly commit the entire working tree. I have developed a habit that I wouldn't feel comfortable if I haven't reviewed the chunks I am going to make into the commit.
While there are many people who don't understand git's staging area, there are far less that understand how to selectively stage/commit chunks, or even that such functionality is available at all.
It should be a crime for people to blindly stage everything. Cleaning up after my colleagues easily falls under the "lost cause" umbrella.
Whereas I don't feel comfortable with untested work, so "git checkout -p" (undo a change) and "git stash -p" (postpone a change) are how I get the workspace clean enough to commit.
In the case of console.log() and debugger breakpoints, that's not a concern.
Often they're disjoint enough that I'm confident that if the end result works, the intermediate commit works, as the sibling commenter mentioned. (Even if not, on many teams it all gets squashed anyway, the intermediate commit message just makes the Pull Request easier to review.)
I can also often easily comment out the uncommitted stuff.
Finally, if I'm really worried about it, after creating the intermediate commit I can just `git stash`, test it, then `git stash pop` and keep working.
Later on, if I notice that I messed something up, I'll create a fixup commit and do an interactive rebase to squash it back into the correct commit.