¿Cómo mover las correcciones de errores a través de las sucursales en DVCS?

Si descubrimos un error en alguna twig, lo solucionamos (ver Nuevo lanzamiento en la image). Pero también nos interesa mover esta corrección a la versión anterior y a la twig de desarrollo principal :

 a -> b -> c (versión anterior)
 |    
 A -> B -> C -> D (versión principal)
     |
     1 -> 2 -> corrección de errores -> 4 (Nueva versión)

svn recordar en svn: properties de fusión (desde svn 1.6, 2009) qué revisión se fusionó con qué twigs. Así que la próxima vez si combina la región de las revisiones, las revisiones fusionadas previamente se saltaron del parche de fusión.

¿Cómo lidiar con DVCS moderno?

¿Necesito hacer un parche simple y aplicarlo a cada twig o existe alguna ayuda de DVCS?

Nota : No puedo fusionar New branche con Main, ya que los sets de cambios anteriores se mueven también a Main branche.

Rebase tampoco es posible ya que muchos desarrolladores tienen acceso a la versión nueva .

Interesante en la respuesta para el esquema de braches con nombre y para el esquema de multirreposito.

PD. Andy sugiere encontrar un padre común para todas las twigs para las cuales el error ha afectado, actualizarlo, aplicar la corrección al error y mover la corrección a las twigs afectadas.

Al actualizar al antiguo set de cambios y realizar cambios, crea una nueva twig. Recomiendo crear una twig con nombre ( asígnele el nombre de ID de error ), por lo que más adelante podrá volver fácilmente.

Hay un problema para encontrar padres comunes en todas las twigs en las que tenemos interés para reparar errores.

La primera solución (que sugiere que Andy ) está usando $ hg / git / bzr culpa y revisa cuidadosamente la salida de todos los files afectados. Esto implica el primer error de corrección en algún nuevo set de cambios antes de que encuentres la culpa de qué set de cambios introduce un error. Entonces necesitas corregir la corrección (parche) al set de cambios padre común.

Otra solución es usar $ hg / git / bzr bisect (también puede realizar actualizaciones manualmente para encontrar la primera revisión en la que se introdujo el error). Esto puede ser una solución expansiva pero más verdadera ya que permite poblar la corrección de errores en cualquier twig en la que haya errores.

Creo que es mejor primero encontrar el primer set de cambios MALO y luego corregir un error, en lugar de primero arreglar un error y luego encontrar el primer set de cambios MALO (excepto en caso de que ya sepas cómo corregir el error). También tener una diferencia que introduce puede ayudar a entender por qué ocurre.

PPS. Con los errores está claro qué twig efectuó para permitir la fusión de cambios en cualquier twig afectada.

Interesante pregunta si pregunta cómo la característica de respaldo de la twig de desarrollo a la twig de lanzamiento. Como puede ver, debe confirmar los sets de cambios de características comenzando con el set de cambios antes de la twig de publicación. Pero cuando desarrolla la function no puede saber dónde necesita la function de respaldo. Con svn: fusionar VCS restring para ti todos los backports. ¿Qué hay de DVCS?

Tú podrías:

  1. Encuentra padre común. Gracias a Novelocrat por este paso.
    git merge-base branch1 branch2 branch3 ...

  2. Pagar el padre común
    git checkout A

  3. crear una nueva twig para corregir errores en
    git checkout -b bugFix

  4. Haga correcciones de errores y comprométalas con la twig bugFix

  5. Sucursal de pago que necesita la corrección de errores
    git checkout branchToApplyFixTo

  6. Fusiona el bugFix en la twig
    git merge bugFix

Podrías git cherry-pick bugfix corrección de errores en cada twig afectada que quieras corregir. Sin embargo, esto generaría una nueva identificación de confirmación para la corrección en cada twig.

Esta es la razón por la cual las personas crean twigs separadas para cada característica o corrección de errores. Entonces, el único truco es asegurarse de que al crear la twig, sea desde un punto que excluya cualquier confirmación que no desee include en cada twig en la que desee fusionar. Si lo olvida, puede volver a basarlo en ese punto antes de realizar una fusión. Si no lo capta hasta que se haya fusionado nuevamente en su nueva twig de publicación como se muestra en su ejemplo, la mejor opción probablemente sea la elección inteligente, aunque eso puede hacer que las fusiones futuras sean muy difíciles si la usa con demasiada frecuencia.