I agree that
git rebase -i is correct way to remove local changes before pushing.
I also agree that if you feel the need to add comments to make the code understandable, they are likely to help your colleagues as well and therefore you should push them.
In either case the comments should be added in separate commit where you don't change anything else then comments. If you add the comments a bit at a time, you may consider combining the commenting commits using
fixup command in
git rebase -i to push in fewer pieces.
If you put the comments on separate lines, blame will only attribute the comment lines to you but not the code lines as they didn't change. Generally the code should not be too wide so it fits on the screen with IDE toolboxes on both sides, so there is rarely enough space at the end of line to do much explaining anyway.
Even if you do touch the lines and the blame will start attributing them to you, there is usually many changes to a line and when looking at a blame annotation, it's rare to be looking for the last change. There is no excuse for not looking at what the last change to the line was and not redoing the blame from the previous revision.
This is one of the reason why preferred option to be used when looking for some code is the "pickaxe",
git log -Stext (and
git log -Gpattern). If you give those only the code on the line, they won't find the commit that added a comment, only the commit that actually introduced the code.
And remember, making the code easier to understand, at least by renaming things to be more descriptive, is better then comments, because comments may become stale as the code is refactored, but the code itself can't.