Jerome Martin <tramjoe.merin@xxxxxxxxx> writes:
> 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 ;-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html