Estoy tratando de elegir un flujo de trabajo de Git que sea más apropiado para nuestro producto. Aquí están los parámetros:
- Hacemos algunos lanzamientos importantes al año, digamos 10 como máximo
- Tenemos varias versiones de nuestro producto activas al mismo tiempo (algunas personas están en v10.1, otras en v11.2, etc.)
- Necesitamos poder trabajar en varias versiones al mismo tiempo (por lo que podríamos estar trabajando en v12.1, pero a medida que llegamos al final de la versión, comenzamos a trabajar en v12.2 al mismo tiempo)
- Necesitamos poder corregir las versiones cuando se encuentran errores críticos
Hasta ahora, esta es la forma en que creo que podría funcionar:
- Se utiliza un repositorio remoto único
- Crear rama 12.1 desde maestro
- Cree ramas de características basadas en 12.1, comprométalas y vuelva a combinarlas en 12.1, presione
- Una vez que necesitemos comenzar a trabajar en futuras versiones, cree una nueva sucursal 12.2 basada en 12.1
- A partir de ese momento, cuando trabaje en una característica para 12.1, cree una ramificación a partir de 12.1, confirme los cambios y combínelos en 12.1 y 12.2, presione
- Si trabaja en una función para 12.2, cree una rama desde 12.2, confirme cambios y combine solo en 12.2, presione
- Cuando se complete la versión 12.1, combínelo en maestro y etiquete la rama maestra con 12.1
- Si se necesita un hotfix, cree una rama de hotfix a partir de la rama de versión más antigua que lo necesite, confirme los cambios y vuelva a fusionarla en todas las ramas de versión para esa versión y versiones futuras que puedan verse afectadas; Si la última rama de la versión estable se vio afectada, combínela en maestra.
Tengo algunas preocupaciones:
- No estoy seguro de que la fusión de las revisiones de las ramas viejas en las ramas nuevas sea un proceso sencillo, especialmente si ha habido muchos cambios superpuestos; ¿Sería más inteligente simplemente revisar manualmente en cada rama en los casos en que parece que habrá conflictos?
- Los modelos de flujo de trabajo que he visto parecen no mantener vivas las ramas de lanzamiento mucho, una vez hecho, el lanzamiento se fusiona en maestro, etiquetado y eliminado. Mi problema con eso es que no tengo una buena idea de cómo administrar el estado de la versión si todo lo que tengo son etiquetas en master, parece más fácil de corregir en una rama y luego tengo una versión a la que siempre puedo volver que tiene la última revisión (incluso puedo etiquetar las revisiones en el lanzamiento). No estoy seguro de que haya una manera de volver al master y de alguna manera tener una copia del lanzamiento con las revisiones aplicadas y actualizar esa etiqueta.
Se agradecen los comentarios sobre cosas que podría haber pasado por alto o mejores formas de lograr cosas dados los requisitos que he especificado.
44
nvie.com/posts/a-successful-git-branching-model
—
Wilbert
Soy consciente de git-flow, pero no veo cómo aborda el trabajo en múltiples versiones simultáneas. Parece que las ramas de lanzamiento ni siquiera están hechas para hacer ningún trabajo, principalmente para hacer la limpieza y luego fusionarlas y etiquetarlas. ¿Qué hago cuando tengo una revisión que afecta a 4 versiones de lanzamiento diferentes? Supongo que podría revisar una versión etiquetada de master, pero una vez que haya hecho arreglos, ¿cómo volvería a trabajar las correcciones que hice en master para esa versión en particular? Parece que sería bastante difícil.
—
Rocket04
Si necesita corregir varias versiones con la misma solución, probablemente primero deba corregir la versión más antigua y combinarla con la más nueva, adaptándose a cada versión. Si trabaja de nuevo a viejo, corre el riesgo de eliminar dependencias de versiones posteriores que complicarán las cosas.
—
axl
Y como menciono en mi respuesta propuesta, la rama maestra no funciona tan bien con múltiples lanzamientos en vivo, por lo que a menos que realmente la necesite por alguna razón, le aconsejaría que no la use.
—
axl