Practica de estrategias de ramas Git

Lo que aprenderas en este tutorial

• Operaciones basicas de ramas
• Feature Branch Workflow
• Diferencias entre Git Flow y GitHub Flow
• Cuando usar merge vs rebase
• Resolucion de conflictos

Que son las estrategias de ramas y por que son importantes

Historia de las estrategias de ramas

Las estrategias de ramas comenzaron a ganar atencion a finales de los 2000 cuando el desarrollo en equipo se volvio mas complejo.

En 2010, Vincent Driessen propuso Git Flow en el articulo “A successful Git branching model”. Esta se convirtio en la primera estrategia de ramas sistematica y se adopto ampliamente.

Posteriormente, GitHub propuso en 2011 el simple GitHub Flow. Gano apoyo como el modelo optimo para equipos que realizan despliegue continuo.

“La estrategia de ramas debe elegirse segun el flujo de trabajo del equipo. No existe una estrategia universal” - Vincent Driessen, articulo complementario de 2020

Por que son necesarias las estrategias de ramas

1. Desarrollo paralelo: Permite desarrollar multiples funcionalidades simultaneamente
2. Aislamiento de riesgos: Aislar codigo inestable de la linea principal
3. Revision de codigo: Garantia de calidad mediante pull requests
4. Gestion de releases: Control de despliegues a produccion

Comparacion de estrategias principales

Operaciones basicas de ramas

Crear y cambiar de rama

# Mostrar lista de ramas
git branch

# Mostrar incluyendo ramas remotas
git branch -a

# Crear nueva rama
git branch feature/login

# Cambiar de rama
git checkout feature/login

# Crear y cambiar simultaneamente (recomendado)
git checkout -b feature/login

# Nuevos comandos desde Git 2.23 (recomendado)
git switch -c feature/login
git switch feature/login

Documentacion oficial: git-branch

Convencion de nombres de ramas

Es importante usar una convencion de nombres consistente en el equipo:

# Desarrollo de funcionalidad
feature/user-authentication
feature/payment-integration

# Correccion de bugs
fix/login-button-crash
bugfix/memory-leak

# Correcciones urgentes
hotfix/security-vulnerability

# Preparacion de release
release/v1.2.0

# Funcionalidades experimentales
experiment/new-algorithm

Mejores practicas: Nombres de ramas en minusculas, separados por guiones, incluir numero de issue para mejor seguimiento (ej: feature/JIRA-123-add-login)

Operaciones con ramas remotas

# Mostrar incluyendo ramas remotas
git branch -a

# Checkout de rama remota a local
git checkout -b feature/login origin/feature/login

# O (desde Git 2.23)
git switch feature/login  # Tracking automatico

# Push de rama a remoto
git push -u origin feature/login

# Eliminar rama remota
git push origin --delete feature/login

# Eliminar rama local
git branch -d feature/login

# Forzar eliminacion de rama no mergeada
git branch -D feature/login

Verificar estado de ramas

# Ver diferencias entre ramas
git diff main..feature/login

# Mostrar ramas ya mergeadas
git branch --merged

# Mostrar ramas no mergeadas
git branch --no-merged

# Mostrar ultimo commit de ramas
git branch -v

Feature Branch Workflow

Es la estrategia de ramas mas basica. Se crea una rama por funcionalidad y se mergea a la rama principal al completar.

Diagrama del workflow

gitGraph
    commit
    branch feature/A
    commit
    commit
    commit
    commit
    checkout main
    merge feature/A
    commit

Escenario practico: Agregar funcionalidad de login

# 1. Actualizar rama principal
git checkout main
git pull origin main

# 2. Crear rama de funcionalidad
git checkout -b feature/login

# 3. Implementar y commitear
# (editar codigo)
git add .
git commit -m "feat: Add login form component"

# (mas implementacion)
git add .
git commit -m "feat: Add login API integration"

# (agregar tests)
git add .
git commit -m "test: Add login validation tests"

# 4. Push a remoto
git push -u origin feature/login

# 5. Crear pull request (en GitHub)

# 6. Merge despues del review

Mejores practicas para pull requests

“Manten los pull requests pequenos. El tamano ideal es que el revisor pueda verificarlo en 20 minutos” - Google Engineering Practices

1. Tamano apropiado: Objetivo de 200-400 lineas
2. Proposito unico: Un PR = una funcionalidad/correccion
3. Descripcion cuidadosa: Incluir contexto, cambios, metodo de testing
4. Self-review: Revisar tu mismo antes de enviar

Git Flow

Estrategia para proyectos con ciclo de release definido. Propuesta por Vincent Driessen en 2010.

Ramas principales

flowchart TB
    main["main (o master)"]
    develop["develop (rama de integracion)"]
    feature["feature/* (desarrollo de funcionalidad)"]
    release["release/* (preparacion de release)"]
    hotfix["hotfix/* (correccion urgente)"]

    main --> develop
    develop --> feature
    develop --> release
    main --> hotfix

Practica de Git Flow

# Crear rama de funcionalidad desde develop
git checkout develop
git checkout -b feature/user-profile

# Al completar funcionalidad, merge a develop
git checkout develop
git merge --no-ff feature/user-profile
git branch -d feature/user-profile

# Preparacion de release
git checkout -b release/1.0.0 develop

# Actualizar version, corregir bugs, etc.
git commit -m "chore: Bump version to 1.0.0"

# Completar release
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"

git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

# Correccion urgente (Hotfix)
git checkout main
git checkout -b hotfix/security-fix

# Despues de corregir
git checkout main
git merge --no-ff hotfix/security-fix
git tag -a v1.0.1 -m "Security patch"

git checkout develop
git merge --no-ff hotfix/security-fix
git branch -d hotfix/security-fix

Herramienta git-flow

Con el comando git-flow las operaciones se simplifican:

# Instalar
# macOS
brew install git-flow

# Ubuntu
apt install git-flow

# Inicializar
git flow init

# Desarrollo de funcionalidad
git flow feature start user-profile
git flow feature finish user-profile

# Release
git flow release start 1.0.0
git flow release finish 1.0.0

# Hotfix
git flow hotfix start security-fix
git flow hotfix finish security-fix

Cuando aplicar Git Flow

Adecuado cuando:

• Hay un ciclo de release regular
• Se necesita soporte de multiples versiones
• Hay equipo de QA

No adecuado cuando:

• Se hace despliegue continuo
• Equipo pequeno
• App web que solo opera la ultima version

Nota de Vincent Driessen en 2020: “Ahora que el despliegue continuo es comun en desarrollo web, Git Flow es excesivo para muchos proyectos. Consideren modelos mas simples como GitHub Flow”

GitHub Flow

Estrategia simple adecuada para despliegue continuo. Recomendada oficialmente por GitHub.

Diagrama del workflow

gitGraph
    commit
    branch pr-1
    commit
    commit
    commit
    checkout main
    merge pr-1
    branch pr-2
    commit
    commit
    commit
    checkout main
    merge pr-2
    commit

Las 6 reglas

1. main siempre esta listo para desplegar
2. Las funcionalidades se ramifican desde main
3. Push regular a remoto
4. Code review mediante pull request
5. Merge a main despues del review
6. Despliegue inmediato despues del merge

Blog oficial de GitHub: GitHub Flow

Practica de GitHub Flow

# Crear rama de funcionalidad desde main
git checkout main
git pull origin main
git checkout -b add-dark-mode

# Desarrollar y commitear (pequeno y frecuente)
git add .
git commit -m "feat: Add dark mode toggle"
git push -u origin add-dark-mode

# Crear pull request (en GitHub)
# Code review
# Pipeline CI/CD se ejecuta automaticamente

# Despues de aprobar PR, merge y deploy
# Eliminar rama despues del merge
git checkout main
git pull origin main
git branch -d add-dark-mode

Cuando aplicar GitHub Flow

Adecuado cuando:

• Se hace despliegue continuo
• Solo se opera la ultima version
• Equipo pequeno a mediano

Trunk Based Development

Estrategia adoptada por equipos grandes como Google y Facebook.

Caracteristicas

• Merge directo a main (trunk) o desde ramas de corta duracion
• Ramas se mergean en 1-2 dias
• Funcionalidades grandes se controlan con feature flags

gitGraph
    commit
    branch short-1
    commit
    checkout main
    merge short-1
    branch short-2
    commit
    checkout main
    merge short-2
    branch short-3
    commit
    checkout main
    merge short-3
    commit

Referencia: trunkbaseddevelopment.com

Merge vs Rebase

Merge

Preserva el historial y crea un commit de merge.

# Merge feature/login a main
git checkout main
git merge feature/login

# Crear siempre commit de merge (--no-ff)
git merge --no-ff feature/login

Resultado:

gitGraph
    commit
    branch feature
    commit
    commit
    checkout main
    merge feature

Rebase

Reescribe el historial de forma lineal.

# Incorporar lo ultimo de main a la rama feature
git checkout feature/login
git rebase main

# Rebase interactivo (organizar commits)
git rebase -i HEAD~3

Resultado (despues de rebase):

• Los commits de feature se colocan linealmente despues de los ultimos commits de main
• No se crea commit de merge

Cual usar

Regla de oro: “Nunca hagas rebase de commits que has compartido con otros”

Organizar commits con rebase interactivo

git rebase -i HEAD~3

Se abre el editor:

pick abc1234 WIP: trabajo en progreso
pick def5678 fix: typo
pick ghi9012 feat: agregar funcionalidad login

# Commands:
# p, pick = usar commit
# r, reword = editar mensaje
# s, squash = unir con commit anterior
# f, fixup = unir con commit anterior (descartar mensaje)
# d, drop = eliminar commit

# Organizar commits
pick abc1234 WIP: trabajo en progreso
squash def5678 fix: typo
squash ghi9012 feat: agregar funcionalidad login

Resolucion de conflictos

Como ocurren los conflictos

flowchart TB
    Original["main: Hello World"]
    OtherMerge["Hello Everyone<br/>(otra persona mergeo)"]
    YourChange["feature: Hello Universe<br/>(tu cambio)"]
    Conflict["Conflicto!"]

    Original --> OtherMerge
    Original --> YourChange
    OtherMerge --> Conflict
    YourChange --> Conflict

Pasos para resolver conflictos

# Cuando ocurre conflicto durante merge
git status  # Verificar archivos con conflicto

# Editar archivo para resolver conflicto

Marcadores de conflicto:

<<<<<<< HEAD
Contenido de la rama actual
=======
Contenido de la rama que intentas mergear
>>>>>>> feature/login

Despues de resolver:

# Agregar archivo resuelto al staging
git add conflicted-file.js

# Completar merge
git commit -m "merge: Resolve conflict between header and footer"

# O, para abortar merge
git merge --abort

Mejores practicas para resolver conflictos

1. Merge/rebase main frecuentemente: Mantener conflictos pequenos
2. Comunicacion: Consultar previamente cuando se edita el mismo archivo
3. Usar herramientas: VS Code, GitKraken y otras herramientas GUI
4. Ejecutar tests: Siempre pasar tests despues de resolver

Resolver conflictos en VS Code

VS Code puede resolver conflictos visualmente:

Accept Current Change  | Accept Incoming Change  | Accept Both Changes

Practica: Simulacion de desarrollo en equipo

Reproducimos un escenario donde 2 desarrolladores experimentan un conflicto.

# 1. Inicializar repositorio
mkdir team-dev-simulation
cd team-dev-simulation
git init
echo "# Team Project" > README.md
git add README.md
git commit -m "Initial commit"

# 2. Rama del desarrollador A
git checkout -b feature/header
echo "<header>Header A</header>" > index.html
git add index.html
git commit -m "feat: Add header by Dev A"

# 3. Volver a main y rama del desarrollador B
git checkout main
git checkout -b feature/footer
echo "<footer>Footer B</footer>" > index.html
git add index.html
git commit -m "feat: Add footer by Dev B"

# 4. Merge feature/header primero
git checkout main
git merge feature/header

# 5. Merge feature/footer (conflicto!)
git merge feature/footer
# CONFLICT (add/add): Merge conflict in index.html

# 6. Resolver conflicto
# Editar index.html para incluir ambos cambios
cat > index.html << 'EOF'
<header>Header A</header>
<footer>Footer B</footer>
EOF

git add index.html
git commit -m "merge: Resolve conflict between header and footer"

Guia para elegir estrategia de ramas

Responde las preguntas para elegir el flujo

1. Despliegas continuamente?

   • Si -> GitHub Flow o Trunk Based
   • No -> Considerar Git Flow

2. Cual es el ciclo de release?

   • Diario a varias veces/semana -> GitHub Flow
   • Semanal a mensual -> Git Flow
   • Varias veces al dia -> Trunk Based

3. Tamano del equipo?

   • 1-5 personas -> GitHub Flow
   • 5-20 personas -> GitHub Flow o Git Flow
   • 20+ personas -> Trunk Based (con feature flags)

Errores comunes y antipatrones

1. Ramas de larga duracion

# Antipatron: Rama sin mergear por semanas
# Los conflictos se vuelven enormes y el merge es dificil

# Mejores practicas: Merge frecuente
git checkout feature/big-feature
git fetch origin
git rebase origin/main  # Ejecutar diariamente

2. Rebase despues de push

# Peligroso! Reescribir commits compartidos
git push origin feature/x
git rebase -i HEAD~3
git push --force  # Sobrescribe cambios de otros

# Seguro: usar force-with-lease
git push --force-with-lease

3. Commit directo a main

# Antipatron
git checkout main
git commit -m "Quick fix"

# Mejores practicas: Siempre pasar por PR
git checkout -b fix/quick-fix
git commit -m "Quick fix"
git push -u origin fix/quick-fix
# Crear PR

Enlaces de referencia

Documentacion oficial y fuentes originales

• A successful Git branching model - Articulo original de Vincent Driessen
• GitHub Flow - Documentacion oficial de GitHub
• Trunk Based Development - Explicacion detallada de TBD

Herramientas

• git-flow - Extension Git para Git Flow
• GitHub CLI - Gestionar PRs desde linea de comandos

Articulos y libros relacionados

• Atlassian Git Tutorials - Branching - Comparacion de workflows
• Pro Git Book - Branching - Explicacion detallada de ramas
• Google Engineering Practices - Mejores practicas de code review