Backporting de características en Git / Subversion

¿Cuál sería la forma preferida de lograr el siguiente flujo de trabajo con Git o Subversion (tengo más interés en la versión de Git , pero la comparación definitivamente será útil):

  • Digamos que tuvimos una versión importante del producto recientemente y hay una twig polisihin específica llamada release-2.0.x .

    El desarrollo luego continuó y varias twigs de características se fusionaron en el master/trunk (más tarde se convertirán en parte de la próxima release-2.1.x ).

  • Ahora, en algún momento, se desarrolló y se fusionó otra característica (a saber, critical-feature ) con el master/trunk . Nos damos count de que esta característica es tan importante, que debemos respaldarla con release-2.0.x .


Aquí hay una pequeña ilustración pseudográfica para el caso descrito. Tenga en count que todo en la parte superior trae diferencias de tree entre release-2.0.x y master/trunk actual y conduce a problemas de fusión (de lo contrario, simplemente podría fusionar la function critical-feature y evitar 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 function de backporting desde la perspectiva de VCS ?

  • ¿Debería hacerse esto como una merge simple de la twig de critical-feature correspondiente con conflictos de resolución de conflictos?

  • ¿O debería hacerse esto como la cherry-pick de la confirmación, que combina la critical-feature en el master/trunk cuando termina? ¿O tal vez incluso como un set de cherry-picks de cherry-picks para cada compromiso en la twig de critical-feature ?

  • ¿Podría aconsejar algo para el procedimiento de resolución de conflictos? ¿Qué debería hacer uno si la diferencia actual entre release-2.0.x y master/trunk es tan grande, que el backporting "ingenuo" genera una gran cantidad de conflictos debido a la refactorización de código y características faltantes o API , que se agregaron después del release-2.0.x ?

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

Toda la idea de las características de backporting se ve rota para mí. Solo los cambios críticos y no destructivos deben ser respaldados. Para las características y mejoras, debe crear una nueva bifurcación e iniciar el período de estabilización.

Consulte el process de publicación utilizado en el propio proyecto Apache Subversion: https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

Depende. Si la característica crítica es relativamente simple y pequeña, puedes hacer varias selects de cereza. Sin embargo, por supuesto, podría causar una gran cantidad de conflictos de fusión, ya que la implementación de la function podría utilizar el código refactorizado. Sin embargo, según tengo entendido, será la solución más fácil. Y la única solución para SVN.

Sin embargo, esta solución no refleja las acciones en el gráfico de historial, confunde.

Con git hay otra opción para volver a establecer la base de la function crítica en la merge-base de merge-base de las twigs master y release-2.0.x . Significa literalmente que debes volver a implementar la function usando el código anterior, que es común para ambas twigs. En este caso, podría fusionar la function rebasada. Si ya fusionó la característica con el maestro, cuando fusionaría la function reestadificada en el maestro, probablemente entraría en conflicto (ya que el maestro ya tiene dicha implementación). Entonces resolverás conflictos, sin embargo, en la mayoría de los casos será fácil, porque los cambios deberían ser casi los mismos.

Lo bueno del enfoque basado en funciones rebasadas es que si encuentra un error en él, puede arreglarlo en la twig de características y fusionar fácilmente las correcciones en el lanzamiento y las twigs principales.

Por supuesto, la nueva configuration podría causar una gran cantidad de conflictos, pero significa que no hay una manera fácil de respaldar la function en la release-2.0.x Tal vez sería más fácil simplemente volver a implementarlo en ese momento.

He desarrollado algunas herramientas específicamente para facilitar este process con git, y la semana pasada escribí una extensa publicación en el blog sobre ellas. En particular, el command git cherry-menu reference en esa publicación puede aceptar una list arbitraria de commits para backport, así que usando git log y tu editor de text favorito, podrías build una list de commits razonablemente cuidadosamente seleccionada que constituya la característica crítica para ser backported, y luego ejecutar algo como:

 git checkout -b release-2.0.y release-2.0.x git cherry-menu cat commits-to-backport.txt 

Esto es similar a la sugerencia de reposition de kan, excepto que el process de backporting es más estructurado, y mediante el uso de notas de git bajo el capó, se obtienen varias funciones extra útiles, incluyendo que todos los metadatos que describen el process se mantienen en varias ejecuciones de git cherry-menu .

Por supuesto, si solo tienes un puñado de commits para backport, kan tiene razón en que también podrías elegir directamente.

Lamentablemente, creo que la respuesta aceptada es ligeramente contradictoria:

Toda la idea de las características de backporting se ve rota para mí. Solo se deben respaldar los cambios críticos y no destructivos. Para las características y mejoras, debe crear una nueva bifurcación e iniciar el período de estabilización.

porque la creación de una nueva sucursal y el inicio de un período de estabilización siguen siendo backporting. ¡La única diferencia es a qué twig decides poner los commit invertidos! Puede ponerlos en la twig original release-2.0.x , o una twig diferente bifurcada, como la twig release-2.0.y que sugerí arriba. En general, es más seguro / más limpio hacer lo último (y supongo que ese es el punto de Ivan), pero realmente eso depende de cómo organices tus repositorys y sucursales. Sin embargo, todavía no evita la necesidad de realizar selects de cerezas y la posible resolución de conflictos.