0% encontró este documento útil (0 votos)
75 vistas5 páginas

Git Flow

Funcionamiento de flujo de GitHub

Cargado por

sebastian.voi94
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
75 vistas5 páginas

Git Flow

Funcionamiento de flujo de GitHub

Cargado por

sebastian.voi94
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Git Flow

Branches Principales:
[main] = master/trunk: Entorno de producción
 Solo recibe merges de los branches: release y hotfix.
 Etiquetados con tags, utilizando un versionado Semántico ej. 1.3.5

1  Cambio mayor

3 Features (puntos de versión)

5 Patchs/Hotfixes

Branch Rules:
 Se requiere un pull request antes de mergear, con la aprobación de 1 persona.
- Se desestima los pull request cuando se pushean nuevos comits al
branch a matchear con main
- Se designa quien puede desestimar pull request

 Restringido el pusheo a este branch, solo podrán delimitados usuarios.

[develop]
 Rama donde se mergearan todos los branches de features. Tendremos los desarrollos
terminados. Una vez que tenemos todos las features deseadas creamos el branch release.
 Solo recibe merges de los branches: feature,release,hotfix.
 De este branch nacen las features.

Branches Soporte:
[feature/ ***]

 Dos dinámicas:
- Branches por feature/ pantalla/usuario  Historial detallado.
- Branches por equipo Historial limpio.
 Nace de develop

[release/numeroversion] = QA
 Aca se realizaran los testeos y en caso de ser necesario se generaran los fixes
previos al lanzamiento de producción.
 NO recibe merges.
 Solo se mergea contra main.  Recomiendo un Squash Merge para no arrastrar
todo el historial de commits al main

[hotfix]
 Fixes urgentes de ámbito productivo.
 Rama derivada de de main
 Se mergea contra develop y main

One Flow
Branches Principales:
[main] = master/trunk: Entorno de producción
 Solo recibe merges de los branches: release y hotfix.

[feature/ ***]
 Nace de main.
 Es el branch del dia a dia de trabajo.
 Si la feature es trabajada por varios compañeros o es de largo desarrollo se pushea
a origen el branch. Si no solo vive en el entorno del desarrollador.
 Una vez finalizada se mergea contra el main:
1) Rebase:

Ventajas: Historial linear, limpio. Más sencillo de indagar.

Desventaja: Revertir toda una feature requiere revertir varios commits Se podría
solucionar con un smash Merge
2) Merge –no-ff (default github )

3)
Rebase +

merge –no–ff

[Link]
have-for-git-merge

[Link]

También podría gustarte