En una twig de corrección de errores de GIT, ¿cómo extraer y luego eliminar otra twig (solo para probarla juntas)?

Me gustaría saber cuál es el process ideal en el siguiente escenario:

  • desarrollar la característica A
  • la característica A hace aparente un error (B) de otra parte del software.
  • crear una bifurcación de bifurcación fuera de A para arreglar B. Sin A, no podemos ver que la corrección de error B es efectiva. (editar: porque solo podemos ver el error cuando A está allí. B siempre ha estado mal, pero no hay ningún síntoma visible hasta que la twig A. la twig A no tiene nada de malo en sí misma)

Ahora en el PR para la corrección de errores, hay una twig A que hace que sea mucho más difícil ver en el diff lo que es la corrección de errores. Además, el revisor técnico corre el riesgo de tener la tentación de revisar las cosas desde A en la twig B de corrección de errores.

Por lo tanto, la twig A en la twig B de la corrección de errores es buena para el revisor de funciones, pero es mala para el revisor técnico.

He tratado de tirar, de anular a A en B, según sea necesario, pero la anulación no parece algo sólido (quizás estoy equivocado)

Mi pregunta aquí no es solo la syntax de git, sino un flujo de trabajo más general para manejar ese caso. Me gustaría evitar obligar a los revisores a hacer el trabajo de git y mostrar cosas lists para revisar.

¿Conoces un buen flujo de trabajo en tal caso? (por favor, agregue los commands de git en su respuesta si es un poco sofisticado)

Me disculpo desde el principio si me sale algo mal, pero algo sobre sus detalles me confundió, aunque lo leí dos o tres veces ("Sin A, no podemos ver que la solución B es efectiva" – ¿cómo puede B estar sin A? , cuando se originó en A?)

En cuanto a la pregunta en el título: si tienes una twig X y qué tirar de otra twig Y para probarla y luego quitarla, sugiero clonar la twig X en una X1 y luego fusionar la twig Y en ella, para que puede ver / probar cómo se comportan juntos. Después de eso, la twig X1 se puede eliminar de forma segura.

 git checkout X; git checkout -b X1; git merge Y; 

Esto también se puede hacer en una request de extracción para una mejor visualización.

Sin embargo, si está desarrollando una twig de características A como se indica en su primera viñeta allí, no hay necesidad de crear una ramificación de corrección de errores desde A , hasta que haya combinado su twig A con la twig principal ( master , o como quiera que lo llame) . La reparación de errores se debe hacer directamente en A.

Mi solución propuesta, al less cómo me gustó trabajar en proyectos hasta ahora, es:

  • crear la twig de características A fuera de la twig master
  • de vez en cuando, para probar que todo funciona bien en A , fusiona la twig master en A ( git checkout A; git merge master; ) -> Esto garantiza que las twigs de características estén siempre actualizadas con tu twig principal. y además hace que el RP final para la twig sea más fácil, ya que habrá less cambios entre los dos.
  • cuando termine de desarrollar en la twig de características A , combínelo mediante una request de extracción

Espero que esto sea útil de alguna manera

Esto realmente depende de en qué estado se encuentre la twig de característica.

  • Si la twig de características se fusiona en el maestro, una twig de revisión es apropiada; git checkout -b <good_hotfix_name_here> fuera de master (a través de git checkout -b <good_hotfix_name_here> ), corrige el comportamiento aberrante, git checkout -b <good_hotfix_name_here> en esa twig y vuelve a fusionarlo en master.

  • Si la twig de características no está fusionada en el maestro, no es necesaria una bifurcación de revisión; arregla el error con la próxima confirmación.

Esta statement es un poco preocupante:

Sin A, no podemos ver que la corrección de errores B es efectiva.

El error debe ser reproducible en A, y no reproducible en B. Si no tiene una forma de validar este código, debe hacer de esto su máxima prioridad absoluta.

Esta afirmación es mucho más preocupante:

Ahora en el PR para la corrección de errores, hay una twig A que hace que sea mucho más difícil ver en el diff lo que es la corrección de errores. Además, el revisor corre el riesgo de tener la tentación de revisar las cosas desde A en la twig B. de corrección de errores.

Esto implica dos cosas:

  • La revisión del código no detectó este error, lo que implica que hay deficiencias en el process de revisión.
  • El código se fusionó antes de que tuviera la oportunidad de verificarse por completo, lo que implica que hay deficiencias en las fases de garantía de calidad y validation.

Sus revisores deben ser lo suficientemente disciplinados como para tratar cada compromiso como una instancia atómica. Si hay un set de requestes de extracción, no las distraiga ninguna otra RP / sucursal / compromiso. Si hay una confirmación que aborda todos los problemas planteados por la revisión, entonces esas correcciones deben estar en esa twig .

Encuentra la base de combinación AB o bisección para la confirmación que introdujo el error. Arréglalo allí y combínalo en A y B (si hay más references afectadas, por ejemplo, tags de liberación para las versiones compatibles, inclúyelas en tu command de fusión-base0).

 # if there's more than A and B involved, include them in this command base=`git merge-base AB` # the bugged commit is often better but # there's no easy command to find it :-) git checkout $base # fix fix commit commit git checkout A; git merge $base # or `git branch fix314 $base` and merge by name # repeat the above for each branch 

Algunas tiendas tienen políticas locales sobre fusiones grabadas, si dicen que no puedes hacer eso, agrega --squash arriba.