Re: Private/public branches/repos workflow

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2011, 04:10 UTC
Message-ID: <7vk4e44gfo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <BANLkTimggn-E+JsXp78_a2P3eWku3oTSbQ@mail.gmail.com>

Jerome Martin <tramjoe.merin@gmail.com> writes:

Show 5 quoted lines

> Could you tell me how you would see usage of rebasing inside the
> workflow you describe ? I am thinking about features (mistakenly)
> implemented on top of the private branch that need later to be release
> in the public branch. Can this be the shortcut to avoid lengthy
> cherry-picks ?

Mistakes and changes of plans can happen, but it's not a big deal.

In the git project itself, even the "master" branch that corresponds to your "private" branch is managed with topic branch workflow, so it is entirely possible that a topic that was originally meant only for the next release turns out to be better backported to the maintenance track.

If you have a private "feature-A" topic with many commits:

                     O   public
                      \
 ...---x---x---x---X---S  private
                        \
                         a---b---...---z  feature-A

and later it turns out that it is better to release them also to the public, instead of cherry-picking the commits to the public, you could at that point do something like this:

    $ git checkout -b public-feature-A feature-A
    $ git rebase --onto public private

which will first create a new branch "public-feature-A" that points at the same tip of "feature-A", and then rebases the commits on that branch that were made since the topic was forked from "private" on top of the tip of the "public" branch, resulting in:

                       a'--b'--...--z' public-feature-A
                      /
                     O   public
                      \
 ...---x---x---x---X---S  private
                        \
                         a---b---...---z  feature-A

and then you may choose when to merge that to the "public" branch. By the time you do this, perhaps the original "feature-A" may have already been merged to "private" after fully tested and audited, like this:

                       a'--b'--...--z' public-feature-A
                      /
                     O   public
                      \
 ...---x---x---x---X---S---x---x---x-----*  private
                        \               / 
                         a---b---...---z  feature-A

and then after you merged "public-feature-A" to "public":

                       a'--b'--...--z' public-feature-A
                      /              \  
                     O---o---...---o--*   public
                      \
 ...---x---x---x---X---S---x---...---x---*  private
                        \               / 
                         a---b---...---z  feature-A

merging "public" back to "private" hopefully may have too many conflicts between the feature-A and public-feature-A branches, as they are supposed to be patch equivalent, to produce this:

                       a'--b'--...--z' public-feature-A
                      /              \  
                     O---o---...---o--*---.   public
                      \                     \
 ...---x---x---x---X---S---x---...---x---*---*   private
                        \               / 
                         a---b---...---z  feature-A

After this you could even garbage collect the two topic branches ;-).