Re: Suggested Workflow Question

[Roger Garvin <yoyodyn@gmail.com>]

Robin Rosenberg <robin.rosenberg.lists <at> dewire.com> writes:

> Don't forget the option of mailing bundles (man git-bundle). Those will give
the effect of push/fetch via
> e-mail. I.e. the exact same commit SHA's get replicated, That may be relevant
for the branches that
> contain your released/official test code.

After trying this out for a little while I and projecting some into the future I
think I am going to have a problem that I am not sure if it really is a problem,
or if Git will "take care of it".  Let me give you a simplistic commit history
to illustrate my point.  In its most basic form you have three branches; dev,
test, prod.  In a perfect world all the development happens on dev, then updates
are pushed to test, and finally after tests pass are pushed out to prod.  So at
a point in time you have something like this:

(P)<--(T)<--(D)

Since I would think (and maybe this is my problem) that ideally Prod is a direct
descendant of Test and Test is a direct descendant of Dev.  However we don't
live in a perfect world, so changes get made on Test that aren't in production
yet, and also in an emergency directly on the Prod branch.  Eventually those
changes get migrated back either through a merge or a rebase (rebase would be
bad since there would be multiple developers using these repos.)  Obviously
making a change to Prod and then merging back to Test, and then merging back to
Dev creates a lot of extra commits.

 (P)<---(T)<----(D)
  ^      ^       ^
   \      \      \
  (P')<--(T')<--(D')

Things get even more complicated when the customer decides to only push certain
features into Prod from test, it looks like cherry pick would be ideal for this
and make it much easier for us.

Is trying to maintain a direct ancestral relationship between Prod, Test, and
Dev worth it?  Am I crazy for even trying to?  I am still a pretty green git
user so it might not be worth it.  But it does seem to me that merges might be
easier and faster if the common ancestor between two commits is closer rather
than farther away in the commit history.

Thanks again for your help.