tutorial - https github com new

Intentando comprender/determinar un flujo de trabajo básico de Git

Question

He estado leyendo este documento popular una y otra vez para intentar redactar mi propio flujo de trabajo de git.

Creo que lo he bajado, pero todavía estoy un poco perdido. Aquí está mi comprensión actual ...

Tenemos dos sucursales que permanecerán siempre activas.

• Maestro: aquí es donde presionaré el código que realmente se implementará en mi servidor de producción y será utilizado por mis usuarios.
• Desarrollo: Esto será ramificado desde la rama maestra. Incluirá todas mis nuevas características, correcciones de errores, etc. que se incluirán en la próxima versión.

Tenemos múltiples ramas temáticas que se ramificarán desde la rama de desarrollo (creo). Una vez que el tema, ejemplo del error como se ha solucionado, fusionamos esa rama de nuevo en la rama de desarrollo. Algunos ejemplos:

• Rama del tema 1: feature-ajaxify-shoping-cart
• Tema Rama 2: bugfix-navbar-font-overlapping

Preparar el lanzamiento

• Tenemos 1 sucursal de lanzamiento a la vez que se ramificará desde la rama de características.
• Ahora extraemos / fusionamos todas las características, correcciones de errores, etc. que queremos incluir en la próxima versión.
• Podemos dejar algunas características en las que hemos estado trabajando que no estarán en la próxima versión (creo).

Creando el lanzamiento

• Una vez que estemos satisfechos con las versiones, podemos fusionar esa rama de la versión en la rama maestra, y nombrar la confirmación algo como ''v1.2.0''.
• También queremos etiquetar ese compromiso con ''v1.2.0'' para que podamos retroceder en el tiempo y ver los lanzamientos.

Notas laterales que he aprendido

La rama maestra es siempre agradable y limpia, y solo contiene confirmaciones que son versiones (creo que es por eso que tenemos una rama de versión separada, ¿no?).

Por favor, hágame saber dónde he estropeado o malinterpretado algo, etc. ¡Gracias!

Answer 1

Tu resumen es preciso: puedes encontrarlo ilustrado en esta hoja de trucos .

Tenga en cuenta que para probar su función con las otras, debe combinarlas para desarrollarlas ( git flow feature finish MYFEATURE ).
Hay otro flujo de trabajo (el flujo de trabajo de Git ) que permite una mejor promoción de funciones (para desarrollar y luego lanzar)

La diferencia es:

• con el flujo de git, se fusionan múltiples ramas de feature en devel (donde descubren si pueden trabajar juntas o no), luego se crea la release desde devel (en cuyo punto la eliminación de características se vuelve compleja) antes de fusionarse de nuevo con devel (y master ).
• con gitworkflow :
  • feature ramas de feature se fusionan en una rama " public " "alfa", que se restablece después de cada lanzamiento (lo que significa, se elimina / se vuelve a crear en la parte superior de la nueva versión)
  • luego, un subconjunto de esas mismas feature se fusionan en una rama " next " ("beta") para la prueba de integración / aceptación. Esa rama " next " ("beta") se recrea de manera similar en la parte superior del master después de cada nueva versión.
  • luego, un sub-subconjunto de ramas de feature se fusiona con el master , para preparar la próxima versión.

Las ramas " public " y " next " (también conocido como '' devel '') nunca se fusionan para master . Son "transitorios" o "efímeros", siempre eliminados / recreados.
Solo las ramas de feature se fusionan con las ramas del ciclo de vida ( public , next , master ). Eso significa que en cualquier momento puede optar por eliminar una feature entre una etapa del ciclo de vida del desarrollo y la siguiente.