Git-flow y master con múltiples ramas de lanzamiento paralelas

86

Estamos tratando de adoptar el exitoso modelo de ramificación de Git implementado por git-flow. Ahora, estamos trabajando en al menos dos versiones, una para la última versión estable y otra para la próxima versión ("vista previa"). Lo que no entiendo es por qué todos los lanzamientos parecen "linealizados" con el maestro y etiquetados allí. ¿Por qué no etiquetar los lanzamientos en sus ramas de lanzamiento? ¿Por qué el maestro en absoluto? ¿O por qué una rama de desarrollo y no usar master para ella?

Agudeza
fuente

Respuestas:

77

En el modelo de git-flow, su "última versión publicada" en realidad se asigna a master, mientras que su "versión de vista previa" se asigna a una releaserama de git-flow . Se bifurca developy finalmente se fusiona mastercuando ocurre el lanzamiento real. Entonces esta se convertirá en su "última versión" y normalmente solo corregirá los errores de esa versión, utilizando hotfixramas de git-flow . De esta manera, su mastersiempre representa el estado más estable de su última versión publicada.

Si desea corregir errores para versiones anteriores o realizar cualquier otro desarrollo allí, bifurcará una supportrama de la confirmación adecuada master(tendrá todas las versiones creadas allí). supportLas ramas aún son experimentales (de acuerdo con los documentos ) y no están bien documentadas. Pero como puede ver en la ayuda de la línea de comandos:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

estas ramas recién se inician y no están destinadas a fusionarse con masterni develop. Por lo general, esto está bien, ya que las correcciones de las versiones "antiguas" o las funciones solicitadas por los clientes para que se implementen en las versiones "antiguas" no pueden o no deben volver a utilizarse master. Si todavía piensa que quiere portar una solución a su línea de desarrollo principal (representada por mastery develop), simplemente comience hotfix, seleccione sus cambios y finalice hotfix.

mstrap
fuente
17
Esto no tiene que ver con un proceso lento desde la prueba hasta el control de calidad y la producción. Puede haber dos (o incluso más, pero digamos dos por ahora) ramas de lanzamiento abiertas, cada una en una etapa diferente de esa canalización y cada una necesaria para permitir la corrección de errores encontrados en la prueba. La rama de desarrollo sería entonces donde se acumulaban las características para una versión cuya rama aún no se ha realizado. En tal situación, una solución en la versión n-2 eventualmente se fusionaría para desarrollarse, pero omitiría la versión n-1, al menos siguiendo el flujo de git estándar. Esto conduciría a una regresión en n-1, corregida eventualmente en el lanzamiento n
Brendan
¿Por qué no se mantendrían las ramas de lanzamiento y una vez que se crea la rama de lanzamiento más nueva, las antiguas evolucionan a una rama de "soporte"?
lkanab
1
¿Por qué las ramas de liberación se "bifurcan" desde el desarrollo y no sólo se "ramifican" desde el desarrollo?
Sandra K
gitflow-avh parece una bifurcación mantenida (es decir, no muerta) del gitflow original. git flow supportno está marcado como experimental.
Timo Verhoeven
9

Parece principalmente un modelo mental con demasiado énfasis en las ramas. Estoy de acuerdo, puedes etiquetar las confirmaciones que liberas en lugar de fusionarlas de nuevo con el maestro.

Sin embargo, la imagen es bonita. La fusión de todo en el maestro da una indicación clara de las versiones en orden temporal en lugar de tener etiquetas de versión esparcidas por todo el gráfico.

Sin embargo, creo que este modelo no funciona para corregir errores en versiones anteriores. Echa a perder el orden ordenado.

  1. Digamos que lanzamos la Versión 1.0.1 y luego agregamos características y lanzamos la 1.1.0.
  2. Descubrimos un error en 1.0.1 y queremos solucionarlo en ambas versiones
  3. Tenemos que agregar 1.0.2 después de 1.1.0 en master y luego directamente atfer (o antes) también 1.1.1.

Para responder a su pregunta: creo que este es un conjunto de reglas que lo convierten en un modelo mental simple en algunos casos. No todas las reglas tienen sentido desde un punto de vista puramente técnico, pero eso no las hace malas. Los modelos mentales son buenos para los humanos.

Sarien
fuente
1
supportLas ramas están diseñadas para corregir errores en versiones anteriores, aunque todavía están etiquetadas como "experimentales".
mstrap
2

Personalmente, creo que el git-flow mencionado es demasiado complicado.

Si está utilizando GitHub, pruebe el GitHub flow(como lo describe Scott Chacon).

Es especialmente útil para la colaboración en múltiples funciones, revisión de código y puede combinarlo con su solución de Integración Continua usando el Commit Status API.

ACTUALIZACIÓN : Hay un nuevo sitio web oficial de The GitHub Flow ™

ACTUALIZACIÓN 2 : Hay una nueva guía oficial (y simplificada) de GitHub para The GitHub Flow ™: https://guides.github.com/introduction/flow/

Haralan Dobrev
fuente
10
El flujo de GitHub solo es adecuado para un contexto no centrado en la publicación: el proceso de git-flow está diseñado principalmente en torno a la "publicación". Realmente no tenemos "lanzamientos" porque implementamos en producción todos los días, a menudo varias veces al día.
Remi Mélisson
10
También agregaría que git-flow realmente no funciona tan bien en un contexto centrado en el lanzamiento que tiene lanzamientos de mantenimiento. Por ejemplo, ¿qué sucede cuando ocurre una versión 1.2.1 después de una versión 1.3.0? Es de suponer que no se puede fusionar con masteruna anomalía de la cronología del trabajo.
Ken Williams
@KenWilliams como se describe en la respuesta de mstrap , para esto son las supportramas. Pero tiene razón, de hecho es una anomalía en la que dichos lanzamientos no se fusionan master, lo que, según tengo entendido, debería contener todos los lanzamientos de producción.
beatngu13
2

En mi caso, tengo dos versiones del mismo software que los conceptos básicos son los mismos pero cada versión tiene algunas características diferentes.

Así que creo dos worktree, es decir, creo dos ramas relevantes de larga duración junto al maestro.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Luego tengo:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Hay un repositorio, pero tengo 3 carpetas separadas una al lado de la otra para cada rama anterior. Y realice los cambios habituales en master. luego fusionarlo con las otras dos versiones.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Los cambios específicos de cada versión también irán en la carpeta correspondiente, y los trabajos en cada proyecto están aislados y el IDE no se confundirá.

Espero que ayude.

vaheeds
fuente
2

Totalmente de acuerdo con @Mot.

Es bueno escuchar las mismas preguntas.

Nuestro equipo también fue buscado por un modelo de ramificación más universal que uno exitoso . Es decir, como @Mot se mencionó anteriormente, la idea principal es evitar la introducción de repositorios adicionales para admitir ramas de lanzamiento * en un repositorio * .git separado, como lo hace, por ejemplo, kernel.org para lanzamientos estables. Pero kernel.org lo hace para minimizar los tamaños descargados, supongo.

Para mí, parece que es más limpio tener master como línea principal para desarrollar .

También hay algunos conflictos en la versión: * fusionar el modelo para dominar y etiquetarlo después con la idea de

use un script de gancho de Git para construir e implementar automáticamente nuestro software en nuestros servidores de producción cada vez que hubo una confirmación en el maestro

porque el acabado (fusión y etiquetado) no es una transacción atómica:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

y si git hook comienza a compilar con soporte de control de versiones automático:

$git describe --tags --long >.ver

entonces es posible construir una versión errónea para:

$ git merge --no-ff release-1.2

Sé que el control de versiones en Successfull one introduce algún proceso de versión mejorada, pero no es automático.

Entonces, en resumen, las diferencias clave que presentamos en el modelo de rama para las versiones, * la combinación y el etiquetado son: - etiquetar la versión en la creación de su rama - mantener la rama de la versión para permitir su mantenimiento en el futuro

mdn
fuente
-2

La rama maestra SIEMPRE debe representar la base de su código de producción, por lo tanto, siempre fusiona el código con el maestro justo después de una versión de producción.

El etiquetado se usa para "memorizar" el código exacto que entró en una versión de producción para que pueda volver más tarde y analizar el código si algo salió mal.

Con esto, en teoría, no debería importar si etiqueta su código en la rama de lanzamiento o en la rama maestra después de fusionarse nuevamente con la maestra. Personalmente, prefiero etiquetar el código en la rama de lanzamiento, ya que este es exactamente el código que se incluyó en la compilación / lanzamiento (asumiendo que algo puede salir mal con la fusión).

El problema con el concepto de rama de desarrollo es que es de un solo subproceso. Brendan en este hilo mencionó una estrategia que podría usarse con un concepto de rama de desarrollo.

Bernie Lenz
fuente
4
¿Qué es una "base de código de producción" si mantiene varias versiones, por ejemplo, v1.0, v1.1, v1.5 en paralelo?
Thomas S.
Production Code Base es lo que está en producción en este momento, por ejemplo, v1.0. Las ramas llevan cambios para las versiones que se implementarán en producción en el futuro, por ejemplo, V1.0.1, v1.1 y v2.0. Una vez que una versión "futura" se implementa en producción, se vuelve a fusionar con la versión maestra, de modo que la versión maestra refleja lo que está en producción. También se fusiona hacia adelante (por ejemplo, v1.0.1 a 1.1 y v2.0) para que los cambios de v1.0.1 no se pierdan cuando v1.1 se lanza a producción.
Bernie Lenz
4
Estoy hablando de mantener múltiples versiones lanzadas, no de versiones futuras.
Thomas S.
4
Parece que no me entiendes. ¿No te imaginas que en algunas empresas se mantienen múltiples versiones de lanzamiento? Microsoft, por ejemplo, también mantiene actualizaciones para Windows 7, 8, 8.1 y 10, entonces, ¿por qué no otras empresas?
Thomas S.
1
Eso es correcto Thomas. Este modelo está orientado a productos que tienen una única versión de producción en un momento dado, como por ejemplo, sitios web. También he usado este modelo para compilaciones móviles, por ejemplo, Android y iPhone, donde la compilación está parametrizada para producir una compilación de Android o iPhone (o ambas) con el mismo número de versión. Tengo curiosidad por conocer su opinión sobre cómo estructurar un modelo de compilación para un producto que tiene varias versiones en vivo en producción en un momento dado, posiblemente con algunos componentes compartidos y algunos componentes diferentes. Háganos saber ...
Bernie Lenz