Use of git rebase in public feature branches_问答_开发者

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.

My team always uses branches for features (wow), we are used to have it just locally, so rebase isn't a problem, but sometimes we wanna show the code of a partially done feature to another developer, so we just publicize it, but then we lose all of the advantages of git rebase, or at least that's what you can read at the web.

I don't understand what's the problem, if the developers working at the same public branch never merge it to any branch (when there is still development on that branch) and when they pull it, they do it with a rebase operation. Any changes made to the branch will be always rebase on top of the remote branch, so never lost and you won't have the problem of having the same commit duplicated.

Append 1:

None of the answers until now showed the problems that will happen and how it will happen, so I will try to be clearer.

I will give an example of a workflow using rebase (badly described in the previously paragraphs, sorry) that I don't see any problem.

Initial state:

master         ==========A
origin/feature           +=====AB
feature user A           +=====AB
feature user B           +=====AB

master get a few commits and user A does a few commits:

master         ==========A=====C
origin/feature           +=====AB
feature user A           +=====AB====D
feature user B           +=====AB

User A does a git pull --rebase (he always does it) to update his branch, nothing new comes, then he rebase to master and push:

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB

(notice the B' is the new commits that still represents the changes B)

Then user B does a few commits:

master         ======开发者_如何学C====A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB======E

User B finally does a git pull --rebase as always, there is no need to rebase on master, so he just pushes:

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D======E'
feature user A                 +=====ACB'=====ACB'D
feature user B                 +=====ACB'=====ACB'D======E'

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.

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: