3 ms·
> 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
by alinajaf 14y ago
> 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 14y agoThis 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 14y agoOr 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.