Guía Definitiva: Flujos de Trabajo Colaborativos con Git

El Flujo de Ramas por Funcionalidad: La Base de Todo

Este es el flujo de trabajo más fundamental. La regla de oro es simple pero poderosa: la rama `main` es sagrada. Cualquier trabajo nuevo se realiza en una rama separada y aislada para garantizar que `main` siempre sea estable y desplegable.

Diagrama de Flujo: Feature Branch

El Ciclo de Vida de una Funcionalidad (Línea de Tiempo)

Paso 1: Sincronizar
Antes de escribir una sola línea de código, asegúrate de tener la versión más reciente del proyecto. Esto previene conflictos futuros.
Paso 2: Ramificar
Crea una nueva rama a partir de `main`. El nombre debe ser descriptivo, por ejemplo: `feature/login-form` o `fix/bug-report-pdf`.
Paso 3: Desarrollar
Trabaja en tu rama. Haz commits pequeños y atómicos. Tu trabajo está completamente aislado y no interfiere con el de los demás.
Paso 4: Pull Request (PR)
Cuando tu trabajo esté listo, sube tu rama y abre un Pull Request. Esta es tu solicitud formal para integrar tus cambios en `main`.
Paso 5: Revisión de Código
Tu equipo revisa el código, sugiere mejoras y aprueba los cambios. Este es el control de calidad más importante.
Paso 6: Fusionar y Limpiar
Una vez aprobado, el PR se fusiona. ¡Tu código ya es parte de la rama principal! Se procede a limpiar las ramas ya fusionadas.

Ejemplo Práctico con Comandos

Veamos cómo un desarrollador llamado "Carlos" implementaría este flujo para añadir un nuevo módulo de reportes.

# 1. Carlos sincroniza su 'main' local con el remoto
git checkout main
git pull origin main

# 2. Crea su rama de funcionalidad
git checkout -b feature/module-reports

# 3. Trabaja en su módulo, haciendo commits descriptivos
# ... escribe código para 'reports.R' ...
git add R/reports.R
git commit -m "feat: Create initial structure for reports module"
# ... añade la UI en 'ui.R' ...
git add ui.R
git commit -m "feat: Add UI elements for report generation"

# 4. Sube su rama al repositorio remoto para iniciar la colaboración
git push -u origin feature/module-reports

# 5. Carlos va a la interfaz web (GitHub, GitLab) y abre un Pull Request.
#    El equipo lo revisa. Una vez aprobado, se fusiona.

# 6. Después de la fusión, Carlos actualiza su 'main' y limpia las ramas
git checkout main
git pull origin main
git branch -d feature/module-reports # Borra la rama local
git push origin --delete feature/module-reports # Borra la rama remota
                

Nivel Profesional: El Flujo de Trabajo GitFlow

Para proyectos más grandes con un ciclo de vida definido (versiones, lanzamientos, parches urgentes), GitFlow proporciona una estructura robusta y predecible. Introduce ramas adicionales con responsabilidades muy específicas.

Diagrama de Flujo: GitFlow

Las Ramas de GitFlow y sus Roles

Main

Propósito: Refleja el estado exacto de producción. Siempre debe ser estable y desplegable. Regla: Nadie hace push directamente aquí. Solo recibe fusiones de ramas `release` y `hotfix`.

Develop

Propósito: Rama principal de integración. Contiene todas las funcionalidades completadas que se incluirán en el próximo lanzamiento. Regla: Es la rama "madre" de todas las `feature` y la "base" de las `release`.

Feature

Propósito: Desarrollar nuevas funcionalidades de forma aislada. Flujo: Nace de `develop` y se fusiona de vuelta a `develop` a través de un PR.

Release

Propósito: Preparar un nuevo lanzamiento (pruebas finales, ajustes). Flujo: Nace de `develop`. Al finalizar, se fusiona a `main` (para el tag) y a `develop` (para incorporar ajustes).

Hotfix

Propósito: Solucionar un bug crítico en producción de forma urgente. Flujo: Nace de `main`. Al finalizar, se fusiona tanto a `main` como a `develop`.

Simulación Práctica: Lanzamiento de la Versión 2.0

# FASE 1: Se ha completado el desarrollo para la v2.0 en la rama 'develop'.
# El líder de equipo inicia la preparación del lanzamiento.
git checkout develop
git checkout -b release/v2.0
git push -u origin release/v2.0

# FASE 2: El equipo de QA prueba en la rama 'release/v2.0'.
# Se encuentran pequeños bugs y se corrigen DIRECTAMENTE en esta rama.
# ... se hacen commits de corrección ...
git commit -m "fix: Correct alignment on main dashboard"
git push

# FASE 3: El lanzamiento está listo. Es hora de fusionar y etiquetar.
# Se fusiona en 'main' para oficializar la versión de producción.
git checkout main
git pull
git merge --no-ff release/v2.0
git tag -a v2.0 -m "Lanzamiento de la versión 2.0 con nuevo dashboard"
git push origin main --tags

# FASE 4: Se fusionan los cambios de la release de vuelta a 'develop'.
# ¡CRÍTICO! Esto asegura que las correcciones hechas en la release no se pierdan.
git checkout develop
git pull
git merge --no-ff release/v2.0
git push origin develop

# FASE 5: Limpieza. La rama de release ha cumplido su propósito.
git push origin --delete release/v2.0
                

El Arte de Resolver Conflictos de Fusión

Un conflicto no es un error, es una señal de que Git necesita ayuda humana. Ocurre cuando dos ramas han modificado la misma línea de un archivo de formas diferentes. ¡Es una parte normal del trabajo en equipo!

Anatomía de un Conflicto

Al intentar fusionar, Git te avisará. El archivo en conflicto contendrá marcadores visuales:

<<<<<<< HEAD (Tus cambios en la rama actual)
app_title <- "Dashboard de Monitoreo ICFES"
=======
app_title <- "Tablero de Seguimiento de Pruebas"
>>>>>>> feature/new-title (Los cambios de la rama que intentas fusionar)

Proceso de Resolución Paso a Paso

# 1. Intentas fusionar 'develop' en tu rama de 'feature' y Git te avisa del conflicto.
git checkout feature/module-reports
git merge develop
> Auto-merging ui.R
> CONFLICT (content): Merge conflict in ui.R
> Automatic merge failed; fix conflicts and then commit the result.

# 2. Revisa el estado para ver los archivos en conflicto.
git status
> Unmerged paths:
>   (use "git add ..." to mark resolution)
>         both modified:   ui.R

# 3. Abre 'ui.R' en tu editor. Verás los marcadores.
#    Edita el archivo, elimina los marcadores y deja el código final deseado.
#    Por ejemplo, decides quedarte con una de las opciones o combinarlas.
#    CÓDIGO FINAL: app_title <- "Dashboard Oficial de Monitoreo ICFES"

# 4. Una vez que el archivo está limpio y guardado, márcalo como resuelto.
git add ui.R

# 5. Completa la fusión. Git abrirá un editor para un mensaje de commit.
#    Normalmente, el mensaje por defecto ("Merge branch 'develop' into...") es suficiente.
git commit
                