Git tries pretty hard to avoid this now; it won't treat fast-forwards as merge commits, it will just fast-forward you. Apparently this was not always the case.<p>Anyway, "git pull --rebase" is your friend. (And so is "git push --force". git pull will DTRT on the other end, so this shouldn't mess anyone else up.)
I've read a number of times that you should never rebase commits that other people may have fetched already. Is this a possible danger here, or will git only rebase your strictly-local commits?
it's funny how some people hate merges and want to do everything with rebasing and fast-forwarding (like this) and others hate ff-ing and think everything should be done with merges to maintain branch history (<a href="http://nvie.com/archives/323" rel="nofollow">http://nvie.com/archives/323</a> thinks the '--no-ff' option should be the default).<p>personally, i use a combination - i tend to rebase when it's only a couple of commits and i merge when there are dozens of commits off, whichever is easier/cleaner. if there are likely going to be conflicts to resolve, rebase is often a bit more difficult, and people tend to have a harder time understanding rebase conceptually so i tend not to encourage it's use to beginners. however, it's interesting to see how each person subtly differently sees how the world of VCS should be, and how Git makes it relatively easy to have such different workflows.
I've been using git-up (<a href="http://github.com/aanand/git-up" rel="nofollow">http://github.com/aanand/git-up</a>) for a while now - it takes care of rebasing _all_ of your tracking branches, as well as stashing & unstashhing any local, uncommitted changes you may have lying around.