Best practices for developing multiple related branches simultaneously

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

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

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'.

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