Git Workflow

Git vs Github

Git y GitHub son dos cosas diferentes. Git gestiona las versiones de archivos mientras que Github es una plataforma en la nube que aloja repositorios Git que nos facilita a los desarrolladores la colaboración en equipo. Github es como la red social de los programadores.

Conceptos clave

Git realiza un seguimiento de tus archivos mediante «snapshots» que registran el aspecto de los archivos de tu repositorio en un momento dado. Es como una bitácora de cada archivo. Nosotros decidimos cuándo tomar una snapshot y de qué archivos, lo que se conoce como «commit». Un repositorio (un proyecto) se compone de un conjunto de commits. Toda la información del repositorio puede duplicarse en el sistema de cada usuario o mantenerse en un servidor central como Github.

Los cambios se hacen en el Working Directory, se preparan con git add en el Staging Area, se confirman con git commit en el Local Repository y luego se sincronizan con el Remote Repository usando git push para enviar y git pull para traer actualizaciones.

Branches

Las ramas en Git son versiones paralelas de un repositorio de código que permiten a los desarrolladores trabajar en diferentes funciones, correcciones de errores o experimentos de forma independiente sin afectar al código principal.

Se utiliza un Git Flow para ramificar nuestros repositorios que nos ayuda a trabajar de manera eficiente y ordenada.

Ventajas de Git Flow:

• Organización clara de las ramas.
• Facilita la colaboración en equipo.
• Permite un control preciso sobre las versiones de software.

Entre las ramas mas comunes utilizadas se encuentran:

• El main: es la rama principal que siempre contiene código en producción.
• El dev o development: el codigo que está en desarrollo activo. Se van integrando funcionalidades aquí antes de lanzar una nueva versión.
• El hotfix/: sirven para resolver errores críticos en producción. Se crean desde main y, al corregir el problema, se integran tanto en main como en dev.
• El feature/: son ramas para trabajar en nuevas funcionalidades. Se crean desde dev y, una vez completadas, se integran nuevamente a dev.

Ejemplo del flujo

1. Se empieza en dev.
2. Se crea una rama feature/nueva-funcionalidad para una tarea específica.
3. Al terminar la funcionalidad, se hace un merge a dev.
4. Se hacen pruebas y ajustes sobre esa rama.
5. Al estar todo correcto, release se fusiona a main.
6. Si después de eso se detecta un bug urgente, se crea un hotfix desde main, se corrige y se fusiona tanto en main como en dev.

Los workflow puede parecer complejo al principio, pero con práctica se vuelve algo cotidiano y que haremos siempre. Es ideal para equipos y proyectos que necesitan mantener orden y control sobre las versiones, errores y nuevas funciones. Y sin duda debes usarlos.