Rebasing pushed commits if only on personal branch

I use multiple machines for my development, so want a way of "self-collaborating". So a personal branch on the remote repository makes sense. Obviously for this branch I would be pushing/pulling a lot (i.e. everytime I start/finish a coding session on a particular machine). I also like to rebase locally to squash/tidyup 开发者_如何学Pythonsome of my commits. I understand that you shouldn't rebase commits that have been pushed to the remote repository. However, are there any problems with me rebasing commits that also exist on the server if they only exist in my private branch (noone else touches this branch)?

Well, git does not really have problem with this. In fact, git's own development process involves a branch on the public server that is rebased quite often (like every day or so). As long as everybody using the branch knows it is being rebased frequently, it's OK.

However you need to remember that you'll have old and new version of the patch without clear indication which supersedes which. Which you can probably easily solve by force-pushing the branch back when you rebase it and thus dropping the old version altogether.

If you have a local branch that you push regularly to a remote repo, but that nobody will use directly (i.e. won't checkout to or merge from your cloned branch), then it is OK to rebase your local branch as many time as you want/need.

But that supposes a good naming convention to identify such "private branches".
And that also supposes you have the right to do a forced push (push -f) in order to override your own history (of the remote private branch) with the rewritten history of your local (private) branch.
That last point isn't obvious, since shared repo often disable that kind of push to avoid "accident" (unless you have some kind of ACL management like Gitolite)