My team is planning a transition to git. We're a big division in a 
corporate environment. I'm "the tools guy"; I guess the latest trendy term 
is DevOps.

Our current workflow involves the equivalent of using cherry-pick to move 
approved bugfixes into the customer release branches. (1) We intend to 
maintain this workflow with git for the conceivable future.

I can rewrite our existing cherry-picking scripts for use with git and that 
is *mostly *no problem, I think, except for one thing: merges. If a dev 
doesn't use fetch --rebase, there could at some point be a non-trivial 
merge as part of their series of commits. Merges, from what I understand, 
present a problem for cherry-pick. I can see two solutions at the moment.

   1. Don't allow any merges in the branch to be cherry-picked from. (This 
   is a bugfixes-only branch, no massive feature work.) We'll likely use some 
   wrappers around git commands, to make 'fetch --rebase' happen automagically 
   for devs. If a dev tries to push a merge, block it and get them to do an 
   interactive rebase until the merge is removed. This might sound crazy, but 
   coming from a non-DVCS background it would not be a very different from our 
   old workflow.
   2. Cherry-pick the merge by introducing what seems to me to be likely 
   hellishly complicated and error-prone code into the cherry-picking script 
   to try to determine the correct merge parent to use when cherry-picking the 

Obviously, I prefer #1 and include #2 only for completeness. But I don't 
really like #1 either.

Does anybody have any thoughts on this? Preferences to these solutions, 
better versions of these solutions, additional different solutions, other 
ways of thinking about the problem?

(While I'm mostly looking for "this is how you do it" comments, I welcome 
*constructive* "you should do it a different way" comments. But ones where 
you just say I'm crazy and doing it all wrong without knowing anything 
about the size of my team, our corporate culture, the number of customer 
release branches we have to support, the penalties we are liable for if 
bugs are introduced in the field, etc, are frankly not helpful at all. 
Honestly, save your breath. :-)



(1) We can't use merge because these bugfixes may be selected for the 
customer branch in a different time order from when they were originally 
committed. Yes, this can introduce dependencies; we're well aware of that 
and can handle it.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to