Git Avanzado & Colaboración

Colaboración profesional con Git

Ya sabes usar Git solo. Ahora aprende a trabajar en equipo sin pisarte con otros developers.

🔀 Pull Requests (PRs)

Un PR es una solicitud para integrar tus cambios a la rama principal. Es el corazón de la colaboración.

Flujo de trabajo con PRs

# 1. Crea una rama para tu feature
git checkout -b feature/nueva-funcionalidad

# 2. Trabaja y haz commits
git add .
git commit -m "Agrega formulario de contacto"

# 3. Sube tu rama
git push -u origin feature/nueva-funcionalidad

# 4. Crea el PR en GitHub
gh pr create --fill
# O ve a GitHub y haz clic en "Compare & pull request"

Anatomía de un buen PR

Ejemplo de descripción de PR

## ¿Qué hace este PR?
Agrega formulario de contacto con validación.

## ¿Por qué?
Los usuarios necesitan poder contactarnos (#123)

## ¿Cómo probarlo?
1. Ir a /contacto
2. Llenar el formulario
3. Verificar que llegue el email

## Screenshots
[imagen del formulario]

## Checklist
- [x] Tests pasan
- [x] Sin console.logs
- [x] Responsive

⚔️ Merge Conflicts

Ocurren cuando dos personas modifican las mismas líneas. No entres en pánico.

¿Cómo se ven?

<<<<<<< HEAD
const mensaje = "Versión de main";
=======
const mensaje = "Tu versión";
>>>>>>> feature/mi-rama

Cómo resolverlos

# 1. Actualiza tu rama con main
git checkout feature/mi-rama
git fetch origin
git merge origin/main
# Aquí aparecen los conflictos

# 2. Abre los archivos con conflictos
# VS Code los marca en rojo/verde

# 3. Decide qué código mantener
# Elimina los marcadores <<<<, ====, >>>>

# 4. Marca como resuelto
git add archivo-con-conflicto.js
git commit -m "Resuelve conflictos con main"
git push

Tips para evitar conflictos

🔄 Rebase vs Merge

Dos formas de integrar cambios. Ambas válidas, diferentes usos.

Merge (conserva historial)

git checkout main
git merge feature/mi-rama

      A---B---C feature
     /         \
D---E---F---G---H main (merge commit)

Rebase (historial lineal)

git checkout feature/mi-rama
git rebase main
git checkout main
git merge feature/mi-rama  # Fast-forward

D---E---F---G---A'---B'---C' main

¿Cuándo usar cada uno?

⚠️ Regla de oro: Nunca hagas rebase de ramas que otros están usando.

👥 Estrategias de branching

GitHub Flow (simple, recomendado)

main ────●────●────●────●────●────
          \      /   \      /
           ●────●     ●────●
          feature    feature

• main siempre deployable
• Features en ramas cortas
• PRs para todo
• Deploy después de merge

GitFlow (empresas grandes)

main     ────────────●────────────●────
                    /            /
release  ──────●───●────────●───●────
              /   /        /   /
develop ●───●───●───●───●───●───●────
         \     /     \     /
          ●───●       ●───●
         feature     feature

• Más complejo, más control
• Ramas: main, develop, feature, release, hotfix
• Para releases planificados

Trunk-Based (equipos expertos)

main ●───●───●───●───●───●───●───●
      \─/     \─/     \─/
      tiny    tiny    tiny

• Commits directos a main (o PRs muy pequeños)
• Feature flags para código incompleto
• CI/CD robusto obligatorio

🔍 Code Review

Revisar código de otros es tan importante como escribirlo.

Como autor del PR

# Antes de pedir review
git diff main...HEAD  # Revisa tus cambios
npm test              # Asegura que pasan tests
npm run lint          # Sin errores de estilo

Como reviewer

Cómo dar feedback constructivo

❌ "Esto está mal"
✅ "Considera usar Optional Chaining aquí para evitar
    el error si user es undefined: user?.name"

❌ "No me gusta"
✅ "Prefiero extraer esta lógica a una función separada
    para mejorar testabilidad. ¿Qué opinas?"

🏷️ Versionado Semántico

Cómo numerar releases: MAJOR.MINOR.PATCH

# Crear un tag de versión
git tag -a v1.2.0 -m "Release 1.2.0: Agrega autenticación"
git push origin v1.2.0

# Ver tags
git tag -l

# Crear release en GitHub
gh release create v1.2.0 --notes "Changelog aquí"

🛠️ Comandos avanzados útiles

# Squash: Unir últimos 3 commits en uno
git rebase -i HEAD~3
# Cambia "pick" por "squash" en los commits a unir

# Cherry-pick: Traer un commit específico
git cherry-pick abc123

# Stash: Guardar cambios temporalmente
git stash
git stash pop

# Bisect: Encontrar qué commit introdujo un bug
git bisect start
git bisect bad                 # Commit actual tiene bug
git bisect good v1.0.0         # Esta versión estaba bien
# Git te va guiando hasta encontrar el culpable

# Reflog: Recuperar commits "perdidos"
git reflog
git checkout HEAD@{2}

# Clean: Eliminar archivos no rastreados
git clean -fd

📋 Checklist de colaboración

• Rama con nombre descriptivo (feature/, fix/, hotfix/)
• Commits atómicos con mensajes claros
• PR con descripción completa
• Tests pasan en CI
• Code review aprobado
• Sin conflictos con main
• Squash o merge según convención del equipo

🍳 Practica

→ Contribuir a Open Source — Tu primer PR a un proyecto real

Enlaces útiles

• 📖 GitHub Flow
• 📖 Conventional Commits
• 📖 Semantic Versioning
• 🎓 Learn Git Branching