Skip to content

Clase 16 — Git, GitFlow y Gestión de Configuración

Resumen Ejecutivo

Sesión práctica (Tema 8C) sobre Git y GitFlow. El profesor revisa comandos esenciales de Git desde línea de comandos, explica los flujos de trabajo (centralizado, por características y GitFlow), y demuestra en directo cómo crear ramas, hacer commits, resolver conflictos y etiquetar releases. Se pone en contexto con el concepto de gestión de configuración como práctica DevOps. GitFlow se presenta con sus ventajas, sus críticas actuales y alternativas como GitHub Flow.

Conceptos Clave

  • Gestión de configuración: arte de identificar, organizar y controlar las modificaciones del software y sus dependencias. Todos los miembros del equipo participan.
  • .gitignore: lista de archivos/carpetas que Git omite (ej. node_modules/, .env). Fundamental para no exponer credenciales.
  • Flujo centralizado: se trabaja directamente sobre main/master. Válido para proyectos personales.
  • Flujo por características (Feature Branch): una rama por feature; se mergea a main cuando está lista.
  • GitFlow: modelo con ramas master, develop, feature/*, release/* y hotfix/*.
  • GitHub Flow: alternativa simplificada a GitFlow, sin rama develop. Orientada a entrega continua.
  • Tags/Etiquetas: marcadores de hitos en el repositorio (ej. versiones 1.0). Anotadas (git tag -a) vs. ligeras.
  • Conflictos de merge: ocurren cuando dos ramas modifican las mismas líneas. Se resuelven eligiendo el código correcto y luego haciendo commit.

Desarrollo del Temario

1. Gestión de Configuración

La gestión de configuración es una práctica clave en DevOps: identificar, organizar y controlar los cambios del software y sus dependencias. En frameworks modernos (Node, Python) las dependencias se declaran en un fichero (package.json, requirements.txt) y no se versionan los binarios.

Regla de oro: nunca subir a un repositorio público credenciales, tokens ni claves de API. El .gitignore es la primera línea de defensa.

2. Comandos Esenciales de Git

# Inicializar repositorio
git init .

# Ver estado del árbol de trabajo
git status

# Alias útiles (buena práctica)
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

# Añadir cambios al índice (staging)
git add .                  # todos los ficheros
git add src/archivo.js     # fichero concreto

# Commit
git commit -m "Mensaje descriptivo"

# Atajo: add + commit en un paso (solo ficheros ya rastreados)
git commit -am "Mensaje"

# Ver diferencias
git diff

# Ver historial de ramas
git log --oneline --graph

# Listar ramas
git branch

⚠️ EXAMEN Conocer los comandos básicos: git init, git status, git add, git commit, git checkout, git branch, git merge, git diff, git tag.

3. Flujo Centralizado

main ──●──●──●──●──●
  • Todo el trabajo va directamente a main.
  • Válido para proyectos personales o unipersonales.
  • Simple pero no escala bien en equipos.

4. Flujo por Características (Feature Branch Workflow)

# Crear rama de feature
git checkout -b feature/componente-saludo

# Trabajar y hacer commits en la feature
git add .
git commit -m "Añadido componente MiSaludo"

# Integrar en main
git checkout main
git merge feature/componente-saludo

Recomendación en equipo: antes de mergear tu feature a main, trae los cambios de main a tu rama para detectar conflictos en local:

git checkout feature/mi-feature
git merge main          # resolver conflictos aquí si los hay
git checkout main
git merge feature/mi-feature

5. GitFlow

⚠️ EXAMEN — El profesor señala explícitamente que GitFlow puede entrar en el examen.

GitFlow es un modelo de ramificación propuesto por Vincent Driessen en 2010. Trabaja con cinco tipos de ramas:

Rama Descripción
master / main Versión oficial en producción. Solo recibe merges de release y hotfix.
develop Rama de trabajo diario. Las features se sacan de aquí.
feature/* Una rama por característica. Sale de develop, se mergea a develop.
release/* Preparación de una versión. Sale de develop, se mergea a master y develop.
hotfix/* Corrección urgente en producción. Sale de master, se mergea a master y develop. 
gitGraph
   commit id: "init"
   branch develop
   checkout develop
   commit id: "base develop"
   branch feature/login
   checkout feature/login
   commit id: "add login"
   checkout develop
   merge feature/login id: "merge login"
   branch release/1.0
   checkout release/1.0
   commit id: "fix bug"
   checkout main
   merge release/1.0 id: "v1.0" tag: "v1.0"
   checkout develop
   merge release/1.0 id: "sync develop"
   checkout main
   branch hotfix/1.0.1
   checkout hotfix/1.0.1
   commit id: "hotfix"
   checkout main
   merge hotfix/1.0.1 id: "v1.0.1" tag: "v1.0.1"
   checkout develop
   merge hotfix/1.0.1 id: "sync hotfix"

Flujo típico:

# Iniciar desde main
git checkout -b develop main

# Nueva feature
git checkout -b feature/info-miembros develop
# ... commits ...
git checkout develop
git merge feature/info-miembros

# Release
git checkout -b release/1.0 develop
# ... ajustes finos, bug fixes ...
git checkout main
git merge release/1.0
git tag -a 1.0 -m "Lanzamiento versión inicial"
git checkout develop
git merge release/1.0    # sincronizar correcciones a develop

# Hotfix en producción
git checkout -b hotfix/1.0.1 main
# ... corrección ...
git checkout main
git merge hotfix/1.0.1
git checkout develop
git merge hotfix/1.0.1   # el hotfix también va a develop

6. Etiquetas (Tags)

# Listar etiquetas
git tag

# Etiqueta anotada (recomendada para releases)
git tag -a 1.0 -m "Lanzamiento versión inicial del producto"

# Etiqueta ligera (sin metadatos)
git tag 1.0

Las etiquetas anotadas almacenan nombre del autor, fecha y mensaje. Son el estándar para marcar releases.

⚠️ EXAMEN Diferencia entre etiqueta anotada y ligera. Comando para crearlas.

7. Críticas a GitFlow y Alternativas

El propio autor (Driessen) revisó su propuesta en 2020:

  • GitFlow es adecuado para software con versiones explícitas y varios entornos en producción (ej. aplicación de escritorio, librerías).
  • Para proyectos web con entrega continua (múltiples deploys al día), GitFlow introduce complejidad innecesaria.
  • La alternativa recomendada en contexto DevOps es GitHub Flow:

GitHub Flow (simplificado): 1. Crea una rama con nombre corto y descriptivo desde main. 2. Trabaja y haz commits en esa rama. 3. Abre una Pull Request para revisión. 4. Resuelve los comentarios. 5. Merge a main y elimina la rama.

main ──●────────────────────────●──
        \                      /
         feature/mi-cambio ──●

El consejo final del autor: "Considera tu propio contexto, no odies y decide por ti mismo."

8. Resolución de Conflictos

Un conflicto ocurre cuando dos ramas modifican las mismas líneas del mismo fichero:

Auto-merging src/components/MiSaludo.jsx
CONFLICT (content): Merge conflict in src/components/MiSaludo.jsx
Automatic merge failed; fix conflicts and then commit the result.

Git marca el conflicto en el fichero:

<<<<<<< HEAD
  <p>Felicidades</p>       {/* lo que había en develop */}
=======
  <p>Estoy muy contento</p> {/* lo que traes de tu feature */}
>>>>>>> feature/cambio-saludo

Proceso de resolución: 1. Editar el fichero y elegir (o combinar) el código correcto. 2. Eliminar los marcadores <<<<<<<, =======, >>>>>>>. 3. git add <fichero>. 4. git commit -m "Resolver conflicto en MiSaludo".

Buena práctica: antes de mergear tu feature a develop, trae develop a tu rama local para detectar y resolver conflictos en tu entorno, sin afectar la rama compartida.

Preguntas Tipo Examen

  1. ⚠️ EXAMEN ¿Qué es GitFlow? Describe sus ramas principales y para qué sirve cada una.
  2. ⚠️ EXAMEN ¿Cuál es la diferencia entre una etiqueta anotada y una etiqueta ligera en Git?
  3. ¿Qué es la gestión de configuración y por qué es importante en DevOps?
  4. ¿Cuándo es apropiado usar GitFlow y cuándo es mejor usar GitHub Flow?
  5. ¿Qué problema resuelve el fichero .gitignore? Pon dos ejemplos de contenido típico.
  6. Describe el proceso para resolver un conflicto de merge en Git.
  7. ¿Qué diferencia hay entre el flujo centralizado y el flujo por características?
  8. ¿Qué hace el comando git commit -am "mensaje"? ¿En qué se diferencia de git add . && git commit?
  9. ¿Para qué sirven los hotfix en GitFlow y en qué ramas deben mergearse?
  10. ¿Qué es una Pull Request y en qué flujo de trabajo se utiliza habitualmente?