Re: Rebasing published branches?

[Antony Male <antony.male@gmail.com>]

On 06/11/2012 8:18 pm, Josef Wolf wrote:
> Hello,
>
> I know, I should never rebase published branches. But...


The major trouble with making rewritten branches public is one of merges.

Assume I have two local repos, A and B, sharing a single remote. I 
create a branch in A, push it to the remote, then fetch it into B. I 
then re-write the branch in A and force-push it, and fetch from B.

As far as B is now concerned, its local history diverges from the 
remote's -- a scenario which must be resolved, usually through a merge, 
before any work can be pushed. Unfortunately, this merge merges together 
the two versions of history -- the old one from B's local history, and 
the new one from the remote -- leading to a mess. If B then pushes, this 
mess is published.

So "published", in the "don't rewrite published branches" sense, means 
"a branch which someone else might regularly pull from, and in doing so 
merge together two versions of history".

In general, remembering that you've pushed rewritten history, and to 
makes sure that you haven't merged two versions of history after a 
merge/pull, is sufficient. After rewriting history on a remote, rebase / 
pull --rebase on a local, un-rewritten branch is sufficient to avoid the 
merging-two-versions-of-history nightmare.

See "RECOVERING FROM UPSTREAM REBASE" in man git-rebase for a more 
in-depth explanation and more discussion of solutions.

> I frequently work on different computers and would like to share my private
> branches across them. When done and the feature is in a good shape, I'd like
> to rebase to clean up history before I make it available to other people.

Rebasing a branch which is about to be deleted (after merging, 
presumably) is generally regarded as fine, provided you're not expecting 
people to base work on the branch before it's rewritten.

Antony