Could anyone explain this with keeping even the remote repositories in mind?
git pull --rebase is the way to go when you want to bring your development branch up to date - those branches are usually not published to others (except maybe for having a look at it) so rewriting history is not a problem and you really don't want merges etc in such a branch.
git merge performs a merge; see the manpage for details - the comand has tons of options which would be too much to explain here.
git rebase performs a rebase, i.e. it rewrites history. It will take your commits up to the point where they diverge from the other branch, remove them temporarily, apply the missing commits from the other branch and then re-apply your commits. git rebase also has an interactive mode where you can remove/modify/combine(squash) certain commits.
Have a look at http://learn.github.com/p/rebasing.html for some nice graphs on how rebases work.