It’s been said that rebasing a branch you’ve pushed out to a public Git repository “may invoke the wrath of the git gods.” For a while I accepted it as gospel that public-facing branches shouldn’t be rebased.
On the other hand, I’m always pushing my development work out into public repos—not least for backups, but also so others (including automated testing systems) can see what I’m doing— and I’ve noticed I often take a branch in one direction, then turn around and try it a different way, which leaves me with a situation like this:
The problem, of course, is that that’s precisely the situation when you’ve rebased a branch that’s been made public. If you just push the local “develop” branch out to the repository, it will fail. Deleting the remote branch first causes the kind of jump in history that makes the git gods angry. So then the remaining choice is to “merge” with the remote branch but discard its changes and push again:
What’s not to like? A lot, it turns out. C6′ is really kind of artificial: it’s exactly like c6 except for parentage, and half of that information (heritage from c4) is meaningless—it’s just there to keep the git gods happy.
Well, as it turns out, the Git gods can be a lot more forgiving than that. For a development branch, it’s perfectly acceptable to have a public change of ancestry. To avoid messes, you just need to get those pulling from your development branch to:
git config branch.name.rebase true
which will cause their work to be rebased upon the remote repository’s current HEAD. The Git Docs warn that this is “possibly dangerous,” but as long as there’s a reflog so the person can rewind to the previous head state, I don’t see what the big deal is. Personally, I’ve even set up my ~/.gitconfig to rebase by default for all branches.