🌿 2.1 · Git y GitHub: control de versiones profesional

🎯 Objetivo del tema

🗺️ Mapa del tema

En el Tema 1.2 aprendiste los comandos básicos de Git: add, commit, push, pull. Ahora darás el salto al uso PROFESIONAL: ramas para trabajar en paralelo sin romper nada, fusiones controladas, Pull Requests con revisión de código, y resolución de conflictos. Esto es lo que usan las empresas de tecnología todos los días.

2.1.1 Por qué las ramas cambiaron todo

Sin ramas, todos los cambios van a main. Si algo se rompe, todo el equipo está bloqueado. Las ramas te permiten trabajar AISLADO: cada feature, cada fix, cada experimento vive en su propia rama. Cuando está listo y revisado, se fusiona con main. Es la base del trabajo en equipo moderno.

El flujo mental correcto

Piensa en main como 'la versión que está en producción, que SÍ O SÍ debe funcionar'. Nunca trabajes directo en main. Crea una rama, trabaja ahí, haz commits, y cuando esté listo, fusiónala con main después de revisarla.

2.1.2 Los 3 comandos de ramas

El 90% de tu trabajo con ramas se reduce a 3 comandos. Memorízalos: crean la rama, te mueves a ella, y la fusionas. Todo lo demás es opcional hasta que lo necesites.

# 1. Crear una rama nueva y moverse a ella
git checkout -b feature/login
# (equivalente a: git branch feature/login + git checkout feature/login)

# 2. Trabajar normalmente: editar, git add, git commit
git add .
git commit -m "Agrego formulario de login"

# 3. Subir la rama a GitHub (la primera vez)
git push -u origin feature/login

# 4. Cuando esté lista, fusionar con main (vía PR en GitHub, recomendado)
#    O en local:
git checkout main
git merge feature/login

# 5. Borrar la rama local (ya no la necesitas)
git branch -d feature/login

Flujo básico de rama

2.1.3 Conflictos: cómo ocurren y cómo resolverlos

Un conflicto ocurre cuando dos personas editan la MISMA línea del MISMO archivo en ramas diferentes. Git no puede decidir cuál versión es 'la correcta': te lo pregunta a ti. La primera vez da miedo. Después de la quinta, es rutina.

Cómo se ve un conflicto en el código

# Cuando haces git merge y hay conflicto, Git marca así el archivo:

<<<<<<< HEAD (tu main)
  const saludo = 'Hola mundo';
=======
  const saludo = 'Hello world';
>>>>>>> feature/ingles

# TÚ decides: borra las marcas y deja solo la versión correcta.
# Después:
git add archivo.js
git commit -m "Resuelvo conflicto en saludo"
# Listo.

Marcas de conflicto en el código

Cómo PREVENIR conflictos

• Trabaja en archivos diferentes cuando sea posible.
• Sincroniza (git pull) ANTES de empezar a trabajar cada día.
• Fusiona feature branches a main FRECUENTEMENTE (no acumules cambios).
• Comunica al equipo en qué archivo estás trabajando.

2.1.4 GitHub: Pull Requests y revisión de código

Un Pull Request (PR) es una petición para que tu rama sea fusionada con otra (usualmente main). Es el momento donde OTRO compañero revisa tu código, comenta, sugiere mejoras, y eventualmente lo aprueba. Es el flujo de trabajo profesional estándar desde hace 15 años.

Cómo abrir un PR en GitHub (paso a paso)

• 1. Sube tu rama: git push -u origin feature/login
• 2. Ve a tu repo en github.com. Aparece un banner 'Compare & pull request'. Haz clic.
• 3. Título descriptivo: 'Agrego login con email y contraseña' (NO 'cambios' ni 'fix').
• 4. Descripción: qué hace, por qué, capturas si hay UI, referencias a issues (#123).
• 5. Asigna revisores: al menos 1 compañero del equipo.
• 6. Espera revisión. Responde comentarios, haz cambios, push de nuevo (el PR se actualiza solo).
• 7. Cuando recibes aprobación, haces clic en 'Merge pull request'.
• 8. Borra la rama (GitHub te lo sugiere).

2.1.5 Buenas prácticas: commits, mensajes, .gitignore

Lo que separa a un junior de un senior NO son los comandos que conoce, sino CÓMO los usa. Mensajes de commit claros, .gitignore bien configurado, y commits pequeños y frecuentes hacen que tu proyecto sea profesional y tu equipo te respete.

El formato Conventional Commits (estándar de la industria)

# Estructura: <tipo>(<alcance>): <descripción>
# Tipos: feat, fix, docs, style, refactor, test, chore

# Buenos ejemplos:
git commit -m "feat(login): agrego validación de email"
git commit -m "fix(api): corrijo error 500 al crear usuario"
git commit -m "docs(readme): actualizo instrucciones de instalación"
git commit -m "refactor(auth): extraigo lógica a un servicio"

# Malos ejemplos (NUNCA hagas esto):
git commit -m "cambios"
git commit -m "fix"
git commit -m "ya funciona"
git commit -m "asdfasdf"

Conventional Commits: el estándar

.gitignore: lo que NUNCA debe subirse a Git

# .gitignore (en la raíz del proyecto)
node_modules/         # dependencias (se reinstalan con npm install)
.env                  # variables de entorno (claves secretas)
dist/                # build de producción
*.log                # logs
.DS_Store            # macOS
.vscode/             # configuración personal de VS Code
.idea/               # configuración personal de JetBrains
*.tmp
*.bak

Ejemplo de .gitignore para un proyecto Node.js

📚 Contenido ampliado

Material adicional, referencias externas verificadas y ejemplos extendidos.