Just a couple more references on this topic:
An especially clear description of rebase workflow:
http://randyfay.com/node/91
github's workflow:
http://scottchacon.com/2011/08/31/github-flow.html
This is not about rebase, but rather about using git in a continuous
rather than episodic (release-oriented) fashion.
My take away from these is that the branch/join strategy is separate
from and more important than merge vs rebase. I guess that the github
branching workflow would work fine with the rebase workflow. They
probably don't need it because they effectively lock the master and
serialize commits with their realtime chat rooms (avoiding the race
problem), the use named branch merges rather than commit messages for
history, and don't use bisect often (less useful for UI/db apps).
For open source and other projects where realtime is not an option,
the rebase workflow is essentially applied at the master level because
the code review typically squashes the feature branch commits into one
about a bug number. At the feature level I think it can help because
the master can move along quickly during the time it takes for your
feature to get reviewed. During that time you will probably branch
your feature to try the next big thing. rebase workflow can help here.
Or so I think at my current level of understanding git...
jjb