¿Cuál sería la forma preferida de lograr el siguiente flujo de trabajo con cualquiera de los dos?Git oSubversion (Tengo más interés en elGit versión, pero la comparación definitivamente será útil):

Digamos que recientemente tuvimos un lanzamiento importante del producto y hay una sucursal específica de polisihin llamadarelease-2.0.x.

El desarrollo luego continuó yvarias ramas características se fusionaron en elmaster/trunk (Más tarde se convertirán en la parte de la próximarelease-2.1.x).

Ahora, en algún punto otra característica (a saber,critical-feature) fue desarrollado y fusionado de nuevo amaster/trunk. Nos damos cuenta de que esta función es tan importante, que tenemos que realizarlarelease-2.0.x.

Aquí hay una pequeña ilustración pseudográfica para el caso descrito. Tenga en cuenta que todo en la parte superior trae diferencias de árboles entrerelease-2.0.x y actualmaster/trunk yconduce a la fusión de problemas (De lo contrario, podría simplemente fusionar elcritical-feature y evita escribir esta pregunta :)

    (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)

Preguntas:

¿Cuál sería la mejor manera de realizar la función de backporting desde elVCS ¿perspectiva?

Si esto se hace como un simplemerge de la correspondientecritical-feature ¿Rama con conflictos de resolución de conflictos?

O debería hacerse esto como elcherry-pick de la comisión, que fusiona lacritical-feature dentromaster/trunk ¿cuando este hecho? O tal vez incluso como un conjunto decherry-picks por cada compromiso en elcritical-feature ¿rama?

¿Podrías aconsejar algo para el procedimiento de resolución de conflictos? ¿Qué se debe hacer si la diferencia actual entrerelease-2.0.x ymaster/trunk es tan grande, que el backporting "ingenuo" conduce a una gran cantidad de conflictos debido a la refactorización del código y las características faltantes oAPI, que fueron agregados después de larelease-2.0.x?

HaceGit oSubversion ¿Tiene algo específico que ofrecer para esta rutina, excepto el enfoque estándar de fusión o selección de cerezas? Supongorebasar no será útil en caso de que la cantidad de conflictos sea enorme, pero, obviamente, podría estar equivocado.