INFOTEP Técnico en Programación de Páginas Web: Control de versiones con Git y trabajo colaborativo

El examen evalúa el modelo de Git y el flujo de trabajo en equipo: commits, ramas, remotos, fusiones, conflictos y buenas prácticas de revisión. No basta con memorizar comandos; hay que entender qué mueve cada uno y qué historia queda.

Modelo básico

Git guarda instantáneas; un commit apunta a un árbol y a sus padres. La rama es un puntero móvil a un commit.
Zonas: directorio de trabajo, staging (git add) y repositorio (git commit). git status muestra el estado.
git fetch descarga sin integrar; git pull descarga e integra; git push publica. El remoto habitual es origin.
git switch -c feature/x crea y cambia de rama. git merge conserva la historia y puede generar un commit de fusión; git rebase reescribe los commits sobre otra base y deja una historia lineal.
git revert crea un commit que deshace otro; git reset --hard mueve la rama y descarta cambios, por lo que es peligroso en historia compartida.

Colaboración

Flujo típico: actualizar la rama principal, crear rama de feature, commits pequeños, push, pull request, revisión, integración y borrado de la rama.
Los conflictos aparecen cuando dos ramas modifican las mismas líneas. Se resuelven editando los marcadores <<<<<<<, ======= y >>>>>>>, añadiendo el resultado y confirmando.
.gitignore excluye dependencias, builds, .env y archivos locales. Un secreto ya confirmado debe rotarse además de eliminarse del seguimiento.
Los tags marcan versiones; las releases suelen apoyarse en ellos.

Ejemplo trabajado

Trabajas en feature/login. Ejecutas git fetch origin, git rebase origin/main, resuelves un conflicto en auth.js, git add auth.js, git rebase --continue, git push --force-with-lease origin feature/login y abres el pull request. Razonamiento: el rebase actualiza tu rama sobre la base más reciente y deja una historia limpia; --force-with-lease sobrescribe tu rama remota solo si nadie más la cambió. No se usaría en main porque reescribiría historia compartida.

Errores que cuestan puntos

Hacer force push a main; subir .env o node_modules; rebasar una rama pública; usar reset --hard sin comprobar cambios; resolver un conflicto sin ejecutar las pruebas; hacer un commit gigante con varios temas; no actualizar la rama antes del pull request.