gitflow - Git-flow y master con múltiples ramas de liberación paralelas.
git flow feature start from another branch (6)
Estamos tratando de adoptar el exitoso modelo de ramificación Git implementado por git-flow. Ahora, estamos trabajando en al menos dos ramas de lanzamiento, una para la última versión estable y otra para la próxima ("vista previa"). Lo que no entiendo es por qué todos los lanzamientos parecen "linealizarse" al maestro y etiquetados allí. ¿Por qué no etiquetar los lanzamientos en sus ramas de lanzamiento? ¿Por qué el maestro en absoluto? ¿O por qué desarrollar una rama y no usar maestro para ella?
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 de arriba. Y hacer los cambios comunes en el maestro. 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.
La rama maestra SIEMPRE debe representar su base de código de producción, por lo tanto, siempre debe volver a combinar el código para dominar justo después de un lanzamiento de producción.
El etiquetado se usa para "memorizar" el código exacto que se incluyó 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 de nuevo a maestro. 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 (suponiendo que algo puede ir mal con la fusión).
El problema con el concepto de rama de desarrollo es que es de un solo hilo. En este hilo, Brendan mencionó una estrategia que podría utilizarse con un concepto de rama de desarrollo.
Parece que en su mayoría es un modelo mental con demasiado énfasis en las ramas. Estoy de acuerdo, usted podría simplemente etiquetar las confirmaciones que libere en lugar de fusionarlas de nuevo con Master.
Aunque la imagen es bonita. Al fusionar todo de nuevo con el maestro, se obtiene una clara indicación de las versiones en orden temporal en lugar de tener etiquetas de versión esparcidas por todo el gráfico.
Creo que este modelo no funciona para la corrección de errores en versiones anteriores, sin embargo. Se mete en el orden ordenado.
- Digamos que hemos lanzado la versión 1.0.1 y luego hemos agregado funciones y lanzado 1.1.0.
- Descubrimos un error en 1.0.1 y queremos arreglarlo en ambas versiones
- Tenemos que agregar 1.0.2 después de 1.1.0 en master y luego directamente (o antes) también 1.1.1.
Para responder a su pregunta: creo que este es un conjunto de reglas que conforma 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 flujo de git mencionado es demasiado complicado.
Si está utilizando GitHub, pruebe el GitHub flow (como lo describe Scott Chacon).
Es especialmente útil para colaborar en múltiples funciones, revisar el código y puede combinarlo con su solución de integración continua utilizando la 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/
Totalmente de acuerdo con @Mot.
Es bueno escuchar las mismas preguntas.
Nuestro equipo también fue cazado por un modelo de bifurcación más universal que por Successfull . Es decir, como @Mot mencionó anteriormente: la idea principal es evitar la introducción de repositorios adicionales para admitir las sucursales de release- * en un repositorio separado * .git, ya que, por ejemplo, kernel.org lo hace para versiones estables. Pero kernel.org lo hace para minimizar los tamaños descargados, supongo.
Para mí, parece que es más limpio tener un master como línea principal para desarrollar .
También hay algunos conflictos en el lanzamiento- * fusionando el modelo para dominarlo y etiquetarlo después con la idea de
use un script de gancho Git para compilar y desplegar automáticamente nuestro software a nuestros servidores de producción cada vez que haya un compromiso 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 start build con soporte de versionamiento automático:
$git describe --tags --long >.ver
entonces se puede construir una versión errónea para:
$ git merge --no-ff release-1.2
Sé que el control de versiones en Successfull one introduce un proceso de versión parcial, pero no es automático.
Para resumir, las diferencias clave que introducimos en el modelo de sucursal para lanzamientos - * fusión y etiquetado son: - etiquetado de lanzamiento en Creación de su sucursal - mantener la sucursal de lanzamiento para permitir su mantenimiento en el futuro
En el modelo de git-flow, su versión "más reciente publicada" se asigna realmente al master , mientras que su "versión de vista previa" se asigna a una rama de release git-flow. Se bifurca desde el develop y, finalmente, se fusiona con el master cuando se produce el lanzamiento real. Entonces esto se convertirá en su "última versión" y, por lo general, solo solucionará los errores de esa versión, utilizando las sucursales de git-flow hotfix . De esta manera, su master siempre representa el estado más estable de su última versión lanzada.
Si desea corregir errores para versiones anteriores o realizar cualquier otro desarrollo allí, tendrá que bifurcar una rama de support desde la confirmación apropiada en el master (tendrá todas las versiones creadas allí). support sucursales de support son todavía experimentales ( según los documentos ) y no están bien documentadas. Pero como se 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 tienen la intención de fusionarse de nuevo con el master ni develop . Por lo general, esto está bien, ya que las correcciones de las versiones o funciones "antiguas" solicitadas por los clientes para ser implementadas en las versiones "antiguas" no pueden o no deben volver al master . Si aún piensa que desea adaptar una solución a su línea de desarrollo principal (representada por master y develop ), simplemente inicie una hotfix , seleccione sus cambios y finalice la hotfix .