Use of git rebase in public feature branches

Question

You can see all over the web people advising to not use git rebase in a public branch, but I can\'t see what\'s the problem, if you always rebase a feature branch.<

Answer 1

http://git-scm.com/book/ch3-6.html

Under the section called "Perils of rebasing"

...you’ll be scorned by friends and family.

Answer 2

When you rebase against public branch, it's perfectly ok.

But when you rebase public branch itself, it is not good for people which are also working with it.

Addition:

When rebase breaks unittest, you won't have an opportunity to git bisect the faulty revision.

In more details:

• you have prepared some code to be added to the branch.
• you have debugged it so it passes all unit tests
• you've git-fetched new changes in the (remote) branch
• now you're rebasing your code against rebased remote branch
• and here unittests get broken
• you're running git bisect and it points at the remote rebase.
• your actions?

Answer 3

If you rebase, you rewrite history. And just like in the real world, if you want to rewrite history, you need a conspiracy: everybody has to be "in" on the conspiracy (at least everybody who knows about the history, i.e. everybody who has ever pulled from the branch).

As long as the circle of people who pull from the branch is tightly controlled, it is fairly easy to get a conspiracy going, however, as soon as you publish that history, it becomes a lot harder. It's not impossible, though: the pu branch in Junio C Hamano's Git repository for example, gets rebased after every release, and that is a widely published repository. The way this works is that the fact that the branch will be frequently rebased and the times when that will happen, are widely documented on the Git website, the Git wiki and the Git mailinglist, and every rebase is announced on the mailinglist in advance so that people can prepare for it.