Programación Web · Capítulo 15
Control de Versiones con Git y GitHub
Aprende a rastrear cambios, colaborar en equipo y nunca más perder tu trabajo con el sistema de control de versiones más usado del mundo.
1. ¿Por Qué Necesitas Control de Versiones?
Imagina trabajar en un proyecto durante semanas y accidentalmente borrar código crítico. Sin control de versiones, ese trabajo se pierde para siempre. Con Git, puedes retroceder a cualquier punto de la historia del proyecto en segundos.
Además, Git permite que múltiples personas trabajen en el mismo proyecto simultáneamente sin pisarse el código entre sí. Es la herramienta más fundamental en el desarrollo de software profesional.
2. Conceptos Clave
| Concepto | Definición |
|---|
| Repositorio | Carpeta del proyecto con todo el historial de cambios |
| Commit | Instantánea guardada del estado del proyecto en un momento |
| Branch (Rama) | Línea paralela de desarrollo independiente |
| Merge | Unir los cambios de una rama a otra |
| Remote | Copia del repositorio en un servidor (GitHub, GitLab) |
| Clone | Descargar una copia completa de un repositorio remoto |
| Pull | Traer cambios del remoto al local |
| Push | Enviar cambios locales al remoto |
3. Configuración Inicial
# Configurar identidad (solo una vez)
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"
# Ver configuración actual
git config --list
# Editor por defecto (VS Code)
git config --global core.editor "code --wait"
4. Comandos Fundamentales
Iniciar y Clonar Repositorios
# Crear nuevo repositorio en la carpeta actual
git init
# Clonar repositorio existente de GitHub
git clone https://github.com/usuario/repositorio.git
# Clonar en una carpeta con nombre específico
git clone https://github.com/usuario/repo.git mi-proyecto
El Ciclo de Trabajo Básico
# 1. Ver estado actual (qué cambió, qué está staged)
git status
# 2. Ver los cambios específicos línea por línea
git diff # Cambios no staged
git diff --staged # Cambios ya en staging
# 3. Agregar archivos al área de staging
git add archivo.js # Un archivo específico
git add src/ # Toda una carpeta
git add . # Todos los archivos modificados
# 4. Confirmar los cambios con un mensaje descriptivo
git commit -m "feat: agregar formulario de contacto con validación"
# 5. Ver historial de commits
git log
git log --oneline # Versión compacta
git log --oneline --graph # Con árbol de ramas
Mensajes de Commit Profesionales
Usa el estándar Conventional Commits: tipo(alcance): descripción
Tipos comunes: feat (nueva función), fix (corrección de bug), docs (documentación), style (formato), refactor (reestructuración), test (pruebas), chore (tareas de mantenimiento).
# Buenos mensajes de commit
git commit -m "feat: agregar autenticación con JWT"
git commit -m "fix: corregir cálculo de precio con descuento"
git commit -m "docs: actualizar README con instrucciones de instalación"
git commit -m "refactor: extraer lógica de validación a utils.js"
# Malos mensajes (no hagas esto)
git commit -m "cambios"
git commit -m "arreglé cosas"
git commit -m "wip"
5. Ramas (Branches)
# Ver todas las ramas
git branch # Ramas locales
git branch -a # Todas (locales y remotas)
# Crear una rama nueva
git branch feature/login
# Cambiar a una rama
git checkout feature/login
# O en versiones modernas de Git:
git switch feature/login
# Crear y cambiar en un solo comando
git checkout -b feature/registro-usuarios
git switch -c feature/registro-usuarios # Forma moderna
# Eliminar una rama (ya mergeada)
git branch -d feature/login
# Eliminar rama sin importar si fue mergeada
git branch -D feature/experimento
Estrategia de Ramas para Equipos
Estructura recomendada (Git Flow simplificado):
main → código en producción, siempre estable
dev → integración de features, base para pruebas
feature/* → nuevas funcionalidades (salen de dev)
fix/* → correcciones de bugs
hotfix/* → parches urgentes en producción (salen de main)
Flujo típico:
1. git switch dev
2. git pull origin dev
3. git switch -c feature/nueva-funcionalidad
4. ... trabajar, hacer commits ...
5. git switch dev
6. git merge feature/nueva-funcionalidad
7. git push origin dev
8. Abrir Pull Request en GitHub para revisar antes de main
6. Merge y Resolución de Conflictos
# Fusionar rama feature al branch actual
git switch dev
git merge feature/login
# Si hay conflictos, Git marca los archivos:
# <<<<<<< HEAD
# tu código en dev
# =======
# código de la otra rama
# >>>>>>> feature/login
# Debes editar manualmente el archivo, elegir qué conservar,
# luego marcar como resuelto:
git add archivo-con-conflicto.js
git commit -m "merge: integrar feature/login resolviendo conflictos"
7. Trabajo con Remotos (GitHub)
# Ver remotos configurados
git remote -v
# Agregar un remoto
git remote add origin https://github.com/usuario/repo.git
# Subir cambios al remoto
git push origin main
git push origin feature/login
# Traer cambios del remoto
git pull origin main # Fetch + merge automático
git fetch origin # Solo descarga, no fusiona
# Primera vez que empujas una rama nueva
git push -u origin feature/nueva # -u configura el tracking
8. Comandos Útiles Adicionales
# Ver qué cambió en un commit específico
git show a1b2c3d
# Deshacer cambios en un archivo (antes de commit)
git restore archivo.js
# Quitar un archivo del staging (sin deshacer cambios)
git restore --staged archivo.js
# Revertir el último commit (mantiene los cambios en staging)
git reset --soft HEAD~1
# Etiquetar una versión
git tag v1.0.0
git push origin v1.0.0
# Guardar cambios temporalmente sin hacer commit
git stash
git stash pop # Recuperar los cambios
9. .gitignore
# .gitignore — archivos que Git debe ignorar
node_modules/ # Dependencias (se reinstalan con npm install)
.env # Variables de entorno secretas
dist/ # Archivos generados por el build
.DS_Store # Archivos del sistema macOS
*.log # Archivos de log
coverage/ # Reportes de pruebas
.vscode/settings.json # Configuración local del editor
# Verificar si un archivo está siendo ignorado
git check-ignore -v archivo.txt
10. Pull Requests en GitHub
Un Pull Request (PR) es la forma estándar de proponer cambios en GitHub. Permite revisión de código antes de fusionar.
- Crea y trabaja en tu rama feature.
- Sube la rama a GitHub:
git push origin feature/mi-cambio.
- En GitHub, haz clic en "Compare & pull request".
- Escribe una descripción clara: qué cambió y por qué.
- Pide revisión a un compañero.
- Responde comentarios y aplica cambios si se solicitan.
- Una vez aprobado, haz merge (generalmente "Squash and merge" para historial limpio).
- Elimina la rama feature después del merge.
Resumen del Capítulo
- Git rastrea el historial completo de tu proyecto; puedes retroceder a cualquier estado anterior y nunca perder trabajo.
- El ciclo básico es: modificar archivos →
git add (staging) → git commit (guardar snapshot) → git push (subir al remoto).
- Los mensajes de commit deben ser descriptivos y seguir una convención (Conventional Commits); son documentación del proyecto.
- Las ramas permiten trabajo paralelo sin interferir; crea una rama por cada feature o fix y fusiona con merge cuando esté lista.
- Los conflictos ocurren cuando dos ramas modificaron la misma línea; debes resolverlos manualmente editando el archivo y haciendo commit.
- Usa .gitignore para excluir
node_modules, archivos .env y cualquier archivo generado automáticamente.
- Los Pull Requests en GitHub son el estándar para revisión de código en equipo antes de fusionar cambios a la rama principal.