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

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?

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.

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.

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/

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.

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

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.