Gitflow

O fluxo de traballo con GitFlow axúdanos a organizar o repositorio Git e o noso traballo:

• Establece un convenio de nomes para as nosas ramas (branches) que permite que todos os membros do equipo saiban que é cada cousa.
• Establece unhas regras comúns a hora de mover información entre ramas.

Estrutura de ramas

En canto a política de ramas, GitFlow propón:

• main como rama principal do proxecto: contén o código de produción. Nunca se debe traballar sobre ela. Desta rama non nace ningunha rama excepto os hotfix.
  • hotfix son as ramas que utilizaremos para corrixir erros críticos encontrados en produción: levan o prefixo hostfix/ seguido do nome da rama (hotfix/fix-form-submit). Nacen sempre da rama main e fusiónanse contra a master e develop, co obxectivo de poñer o hotfix en produción e que tamén este dispoñible para novas versión da rama de desenvolvemento.
• develop como rama de desenvolvemento: nunca se traballará sobre ela. Desta rama saen todas as ramas de feature. A rama develop fusionarase coa main cando vaiamos a despregar o proxecto a través das releases.
  • feature son as ramas sobre as que traballaremos normalmente: levan por defecto o prefixo feature/ seguido do nome da rama (feature/add-avatar). Nacen sempre desde a rama develop e morren cando son fusionadas con esta.
  • bugfix son ramas que se utilizan para corrixir erros que aínda non chegaron a produción. Levan o prefixo bugfix/ seguido do nome da rama (bugfix/fix-wrong-logout-link). Nacen sempre da rama develop.
  • realease son as ramas que utilizaremos para crear novas versións para despregar a produción. Usadas para preparar unha nova versión estable. Créanse a partir de develop cando se decide que esa versión xa está lista. Aquí só se fan correccións menores, optimizacións e tarefas finais como versións e documentación. Unha vez rematada, fusiónase tanto en main como en develop. Exemplo : release/v1.2.0.

Merge Resquest

Un merge request é unha petición formal para fusionar unha rama con outra dentro dun repositorio Git, normalmente como parte dun proceso de revisión colaborativa.

Este permite:

• Solicitar a fusión dunha rama (por exemplo, feature/login) dentro doutra (por exemplo, develop).
• Iniciar un proceso de revisión de código por parte doutros membros do equipo.
• Ver os cambios introducidos, discutir sobre eles e facer comentarios.
• Executar probas automáticas (CI/CD) antes de aceptar os cambios.

Exemplos con GitFlow:

• Cando se remata unha nova funcionalidade (feature/pago-con-tarxeta), créase un merge request para integrala en develop. Antes de facer o merge, o equipo pode revisar o código e comprobar que todo funciona correctamente.
• Unha vez lista unha versión de lanzamento (release/v1.3.0), faise un merge request cara a main para publicar a versión, e tamén cara a develop para incorporar as últimas correccións.