El flujo de git del equipo con las testings en mente

Hemos planeado un flujo de trabajo de git que pensamos que funcionaría bien pero que está teniendo problemas.

En SourceTree tenemos 4 twigs principales

  1. _dev (desde el que creamos twigs de características, cada twig de entidad corresponde a una tarea JIRA)
  2. _qa (al que fusionamos feature-branches una vez que las características están lists y revisadas en _dev)
  3. _next-release (al que fusionamos la twig de function cuando el QA atesting una característica)
  4. master (al que fusionamos toda la twig _next-release cuando finaliza el sprint, fusionando solo las características aprobadas)

También tenemos twigs de versión a las que fusionamos la twig principal cuando se lanza una versión (hacemos esto para asegurarnos de que podamos regresar a esa twig y hacer los ajustes necesarios si nuestro producto es instalable)

Nuestro escenario problemático es:

  1. Dev1 crea feature1 (twig de _dev)
  2. Dev1 combina feature1 a _dev (supongamos que está esperando la revisión del código en este punto)
  3. Dev1 crea y comienza a trabajar en feature2 (branch de _dev otra vez)
  4. Dev1 fusiona feature2 en _dev y pasa la revisión del código.
  5. Dev1 intenta fusionar feature2 a _qa

Resultado : ambos feature1 y feature2 parecen fusionarse en QA, aunque feature1 aún no está listo.

Nos fusionamos haciendo clic con el button derecho en la twig y seleccionando "fusionar featureX en la twig actual"

Tenga en count que tenemos 4 entornos que (deberían) reflejar cada twig para que QA tenga un lugar para verificar las características.

¿Por qué se combinan las características junto con las características que no deseamos fusionar?

¿Cuál es el flujo de trabajo común que permitirá fusionar solo las características validadas en una versión mientras permite que el control de calidad controle las características y permita un historial limpio que refleje el ciclo de vida de cada característica? Dev -> QA -> versión -> versión

Gracias

Primero, una palabra de advertencia: si se queda con este flujo de trabajo y resuelve sus problemas actuales, se enfrentará a otros problemas más sutiles. Los flujos de trabajo como este, que intentan volver a fusionarse con twigs de características individuales en múltiples etapas del ciclo de vida de desarrollo, tienen problemas porque ignoran las posibles interacciones entre los cambios en diferentes twigs.

Dicho esto, centrémonos en algunas de sus preguntas. Su escenario (con ilustraciones) se ve así:

Primero, tienes twigs _dev y _qa . (Los otros, lo dejaremos de lado por el momento, por simplicidad).

 A -- B -- C <--(_dev)(_qa) 

Supongo que comenzamos en un estado donde todo en _dev ha pasado _qa (y, por supuesto, todo lo que ha pasado _qa debe estar en _dev ), por lo que apuntan a la misma confirmación. Esto puede dejar de lado algunos factores complicados que impedirían su flujo de trabajo, pero aún nos da suficiente para entender el problema que enfrenta actualmente. Ahora

Dev1 crea feature1

 A -- B -- C <--(_dev)(_qa) \ D -- E <--(feature1) 

Dev1 combina feature1 a _dev (supongamos que está esperando la revisión del código en este punto)

  (_qa) | A -- B -- C ------ M1<--(_dev) \ / D -- E <--(feature1) 

Dev1 crea y comienza a trabajar en feature2

  (_qa) F -- G <--(feature2) | / A -- B -- C ------ M1<--(_dev) \ / D -- E <--(feature1) 

Dev1 fusiona feature2 en _dev y pasa la revisión del código.

  (_qa) F -- G <--(feature2) | / \ A -- B -- C ------ M1 ------ M2 <--(_dev) \ / D -- E <--(feature1) 

Dev1 intenta fusionar feature2 a _qa

Ok, entonces, ¿qué pasa aquí? Bueno, feature2 es un descendiente de _qa (ya que comenzamos con _qa y _dev en el mismo lugar). Por lo tanto, puede avanzar _qa a feature2 (e incluso si no lo hace, la confirmación de fusión resultante tendrá el mismo contenido que si tuviera). Pero feature2 fue rooteado en M1 ; los cambios de feature1 son alcanzables desde feature2 pero no alcanzables desde _qa , por lo que la fusión los includeía.

Si hubiéramos empezado con _qa siendo accesible desde _dev (en lugar de los dos apuntando a la misma confirmación), exactamente el mismo análisis se mantendría. Si, por alguna razón, _qa contenía cambios no accesibles desde _dev , podríamos tener algo así como

  Q <--(_qa) F -- G <--(feature2) / / \ A -- B -- C ------ M1 ------ M2 <--(_dev) \ / D -- E <--(feature1) 

En ese caso, git encontraría una base de combinación entre _qa y feature2 , es decir, un ancestro común. Eso sería B Luego combinaría "cambios entre B y _qa " con "cambios entre B y feature2 . De nuevo, los cambios entre B y feature2 incluyen los cambios que fueron realizados por feature2 porque feature2 fue rooteado en M1 (es decir, un punto después de que feature1 se fusionó en )

En todos los casos, el punto es el mismo: en su mayor parte (incluso durante una combinación), git no ve las confirmaciones (o deltas entre ellas) como "pertenecientes a" esta twig o esa twig. En cambio, le importa si un cambio está en el path hacia la base de combinación.

Una situación en la que normalmente se puede hacer git para ver los cambios "desde una twig" de forma aislada sería una rebase . Sin embargo, su flujo de trabajo necesitaría una revisión importante para aprovechar esto, y daría lugar a otras complicaciones. No es el path que recomendaría aquí.

Otra forma en que podría parecer que podría arreglar su flujo de trabajo sería exigir a los desarrolladores que inicien nuevas twigs de características en la base de fusión entre _dev y _qa . PERO esto solo puede _qa (a less que los cambios siempre "se mantengan en order" una vez que lleguen a _qa , lo cual no es una suposition razonable, especialmente si QA descubre defectos). Además, esto aumenta el aislamiento entre el trabajo realizado para una característica frente a la siguiente, lo que significa que probablemente tendrá más conflictos de fusión para tratar.

De todos modos, creo que eso aborda su pregunta por qué . En cuanto a qué :

Bueno, si bien usó "git flow" como un término genérico para "una estrategia de bifurcación y fusión", en realidad gitflow es el nombre de una estrategia específica de bifurcación y fusión. Sugiero leer sobre esto. Las necesidades que ha descrito no son únicas o incluso poco comunes, por lo que, en lugar de pensar que debe personalizar este flujo para satisfacer esas necesidades, analice cómo las personas satisfacen esas necesidades utilizando este flujo.