"Normal" git development (without rebasing) naturally creates a branching history when two people make changes based off a common root. As was explained above,

"Normal" git development (without rebasing) naturally creates a branching history when two people make changes based off a common root. As was explained above, rebasing causes this branching history to be rewritten into a linear one. The alternative is merging, where you cause Git to record what actually happened -- which is that two changes occurred simultaneously and you explicitly brought them in sync again. Sometimes (often) this is what you want -- it's especially useful for longer-lived branches of work, where having the history of the branch can be valuable in itself. Also, if you share a commit with someone, you can no longer safely rebase it! The reason is that part of the definition of a commit is its set of parents -- the commits it depends on (usually 1, but can be 2 or more for a merge commit). When you rebase, you are rewriting all the parents, so you end up creating a whole stream of new commits and discarding the old ones. If you then attempt to share history with someone who has the old ones, presumably Git will become confused. (I've never actually run into this problem, but I don't use rebasing much.)