Best practices for developing multiple related branches simultaneously

Best practices for developing multiple related branches simultaneously

[Wink Saville]

Hello,

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.

For example:

*) git-checkout branchA
*) change some files on branchA
*) git-commit -a
*) git-checkout branchB
*) git-rebase branchA
*) git-checkout branchC
*) git-rebase branchB

This seems to work, but is somewhat arduous and I
was wondering if there is a better way?

Also, I'd like to checkout and work on all three branches
simultaneously. As is implied above, what I do at the moment is
use one repository and to switch branches I use git-checkout, so
as not to lose work when switching I need to commit before switching.
Sometimes I'd rather not commit as I may just want to look at what was
in another branch, possibly unrelated to this series. What is a good
way of handling this situation?

Regards,

Wink Saville

Re: Best practices for developing multiple related branches simultaneously

[Junio C Hamano]

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

> 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?

Re: Best practices for developing multiple related branches simultaneously

[Wink Saville]

> > 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?
>

By design they depend upon each other, the other option would
be to work on  them in one branch but submit them separately.
But I don't know of a good way to segregate them for submission
as there are modifications to the same files.

Actually, even now using separate topics, its not as easy as I'd
like if I want to make a "perfect" patch. If I want to make an "imperfect"
patch of a particular topic its very easy, for example:

*) git-checkout branchC
*) git-format-patch -s -n -o patches/branchC branchB

But this will have all my random commits in the patch, to make a
"perfect" patch for branchC I make another branch, branchC1, off
of branchB and use git-am to apply the imperfect patch to branchC1.
and then do another series of commits on branchC1 to make a
perfect patch by choosing the order I commit the files in the final series
of commits.

As you can see my approach to the perfect patch isn't very easy.
I was looking at stgit as a possible solution, but haven't tried it yet
and I've never used quilt so I'm not sure its right either.

Anyway, thanks for the help and if you've got any other suggestions
they would be much appreciated.

Regards,

Wink