Qual seria a maneira preferida de atingir o fluxo de trabalho a seguir comGit ouSubversion (Eu tenho mais interesse noGit versão, mas a comparação será definitivamente útil):

Digamos que tivemos um lançamento importante do produto recentemente e há um ramo polisihin específico chamadorelease-2.0.x.

O desenvolvimento então continuou evários ramos de recurso foram fundidos nomaster/trunk (eles mais tarde se tornarão parte do próximorelease-2.1.x).

Agora, em algum momento, outra característica (a saber,critical-feature) foi desenvolvido e fundido de volta aomaster/trunk. Percebemos que esse recurso é tão importante, que temos que retroceder pararelease-2.0.x.

Aqui está uma pequena ilustração pseudográfica para o caso descrito. Note que tudo no topo traz diferenças de árvore entrerelease-2.0.x e atualmaster/trunk eleva a problemas de fusão (caso contrário, eu poderia simplesmente mesclar ocritical-feature e evite escrever essa pergunta :)

    (features added since 2.0.x, which
     should not be backported)
              ^   ^    ^
              |   |    |    (code refactorings done
              |   |    |     in master/trunk)
              \   |    /     (*) (*) (*)          
-------------------------------------------------------> master/trunk
      |                                          |
      |                                          |
      |                                          |
      \ release-2.0.x                            \ critical-feature
                                                   (should be backported)

Questões:

Qual seria a melhor maneira de executar o recurso backporting a partir doVCS perspectiva?

Isso deve ser feito como um simplesmerge do correspondentecritical-feature ramo com conflitos de resolução de conflitos?

Ou isso deve ser feito como ocherry-pick do commit, que mescla ocritical-feature para dentromaster/trunk quando estiver feito? Ou talvez até como um conjunto decherry-picks para cada commit nocritical-feature ramo?

Você poderia aconselhar algo sobre o procedimento de resolução de conflitos? O que se deve fazer se a diferença atual entrerelease-2.0.x emaster/trunk é tão grande, que backporting "ingênuo" leva a uma enorme quantidade de conflitos devido a refatoração de código e falta de recursos ouAPI, que foram adicionados após orelease-2.0.x?

FazGit ouSubversion tem algo específico a oferecer para essa rotina, exceto a abordagem de mesclagem padrão ou escolha seletiva? eu acho querebasing não será útil caso a quantidade de conflitos seja grande, mas, obviamente, posso estar errado.