[alinajaf]

> The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

<rant>

When one is on a development team that doesn't really understand how rebase (or git for that matter) works and are suitably trigger happy with `git pull --rebase`, this itty bitty caveat makes origin a minefield when working with branches.

In that situation, one would honestly wish one were using svn instead. Then at least one could use git-svn locally and treat trunk as origin/master, which is what ones team really wants.

</rant>

[snprbob86]

This is where smaller code projects with clearer dependencies come in to play. You can designate maintainers, integrators, reviewers, etc on a per-project/per-boundary basis. This means that failure to understand rebase has severely localized effects. As a bonus, you'll get better factored code backed by developers with an enhanced sense of ownership.

[alinajaf]

Or you know, you could just spend a few hours learning about how a tool you're probably going to be using for over a decade works.