Flujo de Git frente a flujo de Github

Básicamente, hay dos formas de administrar los proyectos de software en GIT Git flow y GitHub flow . Estos dos flujos pueden ayudarlo a administrar su proyecto y optimizar todo su flujo de trabajo en el equipo.

Flujo de GitHub

El flujo de GitHub es realmente muy simple de adaptar, ya que este flujo no tiene lanzamientos porque su implementación en producción ocurre todos los días. Hay dos tipos de ramas involucradas en este flujo, la rama maestra y la rama característica .

GutHub Flow

  • Cuando está trabajando en un proyecto, debe crear una rama de función a partir de su rama maestra y trabajar en ella.
  • Una vez que haya desarrollado una función y probado los cambios por completo, puede crear una solicitud de extracción (PR) para la rama principal.
  • Una vez que los cambios en la rama de funciones se revisan y aprueban con respecto a la solicitud de relaciones públicas, la rama se fusiona con la rama maestra.
  • Las sucursales le permiten trabajar en nuevas funciones y corregir errores.

¿Cómo crear una nueva rama de funciones a partir de la rama maestra mediante el proceso de pago?

$ git checkout -b <branch-name>

Por ejemplo, desea crear una nueva rama ‘Característica’ a partir de la rama ‘maestra’. Para lograrlo, debe llamar al comando «git checkout» con la opción «-b» y agregar el nombre de la rama como ‘Característica’

Al usar el comando ‘git checkout’, está creando una nueva rama y está cambiando a la nueva rama automáticamente.

Para explicar el flujo de GitHub en pasos simples, consulte los siguientes puntos:

  • Debe crear una nueva rama a partir de la rama maestra cuando desee desarrollar una nueva función o corregir errores.
  • Confirme sus cambios en la rama de funciones localmente y siga impulsando su trabajo en la misma rama de funciones.
  • Cuando necesite ayuda o comentarios y crea que ha desarrollado la función por completo y que su rama está lista para fusionarse, abra una solicitud de extracción (PR)
  • Cuando alguien haya revisado y aprobado los cambios de la rama de función, puede fusionarlo con el maestro.
  • Una vez que se fusiona y se empuja a maestro, puede implementarlo de inmediato.

Flujo Git

Git Flow suele ser más complicado que el flujo de GitHub. Se utiliza cuando su software tiene el concepto de «lanzamiento». Este flujo funciona perfectamente cuando trabajas en un equipo de uno o más desarrolladores y colaboran en la misma función.

Git Flow

Ramas principales en Git Flow

  • Maestro: representa el estado del código listo para la producción
  • Desarrollar: representa los últimos cambios de desarrollo

Rama característica

Cada vez que uno tiene que trabajar en una nueva función, se ramifican desde la rama de desarrollo y trabajan en los cambios en la rama de funciones. Una vez que se completen los cambios en la rama de características, solicite una solicitud de extracción a la rama de desarrollo. Una vez que se revisa y aprueba la función, estos cambios se pueden volver a fusionar con la rama de desarrollo.

Sucursal de liberación

  • Las ramas de lanzamiento se ramifican desde Desarrollar y se fusionan nuevamente para desarrollar y dominar.
  • Debe realizar el código prelanzado de corrección de errores en esta rama, las correcciones de errores pueden fusionarse continuamente con la rama de desarrollo.
  • Todas las características previstas para el lanzamiento deben volver a fusionarse para desarrollar la rama
  • Debe crear una nueva rama de versión con un nombre que refleje el nuevo número de versión.
  • Si la rama de lanzamiento se lanzará en el servidor de producción, fusione la rama de lanzamiento con el maestro, cree una etiqueta para futuras referencias, luego vuelva a fusionar los cambios para desarrollar la rama y luego elimine la rama de lanzamiento.

Rama de revisión

  • Las ramas de HotFix se ramifican desde el maestro y se vuelven a fusionar para desarrollar y dominar.
  • Solucione el error en la rama de revisión, cuando termine con la corrección de errores, combine la rama de revisión con el maestro, luego cree una etiqueta para futuras referencias y vuelva a combinar los cambios para desarrollar la rama. Por último, Eliminar rama de revisión.

Desde una perspectiva de CI/CD, solo queremos implementar las ramas de desarrollo y maestra respectivamente. La rama de desarrollo debe enviarse a entornos de desarrollo o prueba. La rama maestra termina en entornos de producción.

Publicación traducida automáticamente

Artículo escrito por deepeshnagpal y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *