Re: Best practices for developing multiple related branches simultaneously

From: Junio C Hamano <junkio@cox.net>
Date: Apr 8, 2007, 04:54 UTC
Message-ID: <7v7isnbh40.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <d4cf37a60704071957r7bb907eg84180097a4594f43@mail.gmail.com>

"Wink Saville" <wink@saville.com> writes:

Show 22 quoted lines

> A couple of questions on how to manage a series of
> hierarchically related branches.
>
> I've created something like this:
>
> ----> master
>    \----> branchA
>         \----> branchB
>              \----> branchC
>
> With the intent to be able to create three separate
> patches that others can make to master and also continue
> development on all three branches simultaneously.
>
> What I'm doing at the moment is to "git-checkout"
> one of the three branches A, B or C and make changes.
> Note; I don't make changes to master as it represents the
> upstream code and will be pulling from it periodically.
>
> If the branch is a parent to a child and I want the
> new changes in the parent to be seen by the children I
> recursively check out the immediate child do a git-rebase.

This depends on how you plan to ultimately use the result of work done on the topic branches. If you are feeding the completed series as a set of patches to upstream to be applied (and eventually contained when you pull into 'master'), this "master is always pristine, topics are constantly rebased on top of it" pattern is a reasonable thing to do. With a few caveats:

 * It is harder to share the topics across multiple people as
   you are constantly rebasing.

 * As you found out, you need to keep track of which ones come
   directly on top of 'master', which ones are second generation
   on top of which other branches, etc.

You do not necessarily have to be constantly rebasing on top of 'master', though. You can instead:

 - Keep 'master' pristine (as your upstream does not 'pull' from
   you);

 - When you start a topic, try to fork from the branch closest
   to 'master' (preferrably 'master' itself);

 - When there are new changes on 'master' (or topic that is
   closer to 'master') that affect the work you did on your
   topic, merge 'master' into the topic, and keep going, never
   rebasing the topic.  This 'merging from upstream as needed'
   includes the case where your submission was applied to
   'master'.

As you go, when all the work you are done on a topic has been applied to 'master', your 'merge from master' would result in the tree of that topic exactly match the tree of 'master'. At that point you can discard that topic branch.

The set of changes you have on a topic that have not been applied to 'master' can be found using 'git-cherry'.

> Also, I'd like to checkout and work on all three branches
> simultaneously.

Julian Phillips's git-new-workdir script in contrib/workdir may suit your needs.

Having said all that, the first advice is to avoid second generation topic that depends on another topic when possible. Is your branchB absolutely need to depend on branchA?