Re: Suggested Workflow Question

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

the effect of push/fetch via

for the branches that

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.