Git para estudiantes: del primer commit al flujo de trabajo real en empresa

En clase, Git se suele quedar en tres comandos: add, commit y push. Con eso apruebas. El problema llega cuando entras en una empresa y descubres que el trabajo real va de ramas, revisiones y conflictos, y que nadie toca main directamente.

Esta guía empieza por lo básico, pero llega hasta donde de verdad lo vas a necesitar. Lo he escrito después de ver en mis prácticas todo lo que me faltaba.

La idea de fondo: tres zonas

Casi todos los líos con Git al principio vienen de no tener claro que tus archivos pasan por tres sitios distintos:

1. El directorio de trabajo: tus archivos tal cual, con los cambios que acabas de hacer.
2. El área de preparación (staging): lo que has marcado para incluir en el próximo guardado. Aquí es donde entra git add.
3. El repositorio: el historial de guardados confirmados. Aquí entra git commit.

Cuando entiendes que add no guarda nada, solo selecciona qué va a guardarse, la mitad de la confusión desaparece.

El comando que más vas a usar, con diferencia, es el que te dice en qué estado está todo:

git status

Acostúmbrate a lanzarlo antes y después de cada cosa. Te ahorra la mayoría de los sustos.

El ciclo básico

git add .
git commit -m "Añado el formulario de contacto"
git push

Sobre los mensajes de commit: escribe qué hace el cambio, no qué archivos tocaste. «Añado validación al formulario de registro» sirve; «cambios» o «arreglos» no le dicen nada a nadie, empezando por ti dentro de dos semanas.

Y haz commits pequeños y frecuentes. Es mucho más fácil localizar dónde se rompió algo entre diez commits pequeños que dentro de uno gigante llamado «proyecto terminado».

Ramas: lo que cambia todo

Una rama es una línea de trabajo paralela. Te permite desarrollar algo nuevo sin tocar el código que ya funciona. En clase quizá no las necesites; en una empresa es innegociable.

git switch -c feature/formulario-albaranes

Eso crea la rama y te cambia a ella. Para moverte entre ramas que ya existen:

git switch main
git branch

Verás mucha documentación antigua que usa git checkout para esto. Sigue funcionando, pero switch (para cambiar de rama) y restore (para descartar cambios) son más recientes y menos confusos, porque checkout hacía las dos cosas y más.

El flujo que te vas a encontrar trabajando

En la mayoría de equipos, incluido donde estoy de prácticas, funciona así:

1. Te pones sobre develop y la actualizas con git pull.
2. Sacas tu rama desde ahí, nunca desde main.
3. Trabajas, haces commits y subes con git push -u origin nombre-de-tu-rama.
4. Abres un pull request y esperas a que lo revisen.
5. Corriges lo que te comenten y, cuando lo aprueban, se integra.

Nadie empuja directamente a main. De hecho, en la mayoría de repositorios está bloqueado para que no se pueda.

Conflictos: no son el fin del mundo

Un conflicto aparece cuando dos personas han tocado las mismas líneas del mismo archivo y Git no sabe cuál vale. Te lo marca así dentro del archivo:

<<<<<<< HEAD
const titulo = "Mi web";
=======
const titulo = "Mi portfolio";
>>>>>>> develop

Arriba está tu versión, abajo la que viene de la otra rama. Lo que tienes que hacer es editar el archivo y dejarlo como debe quedar, borrando también las líneas de marcas (<<<, === y >>>). Después:

git add archivo-en-conflicto.js
git commit

El error clásico de principiante es quedarse con las dos versiones y dejarse alguna marca dentro. Luego el código no compila y no entiendes por qué. Revisa siempre el archivo entero antes de dar por resuelto el conflicto.

Truco para tener menos conflictos: actualiza tu rama a menudo con los cambios de la rama principal, en vez de dejarlo para el final. Cuantos más días pasen, más grande será el choque.

Cómo deshacer errores

Esta es la sección que de verdad te va a salvar, y la que nunca aparece en las guías básicas.

He modificado un archivo y quiero dejarlo como estaba:

git restore archivo.js

He hecho git add de algo que no quería incluir:

git restore --staged archivo.js

Me he equivocado en el mensaje del último commit (siempre que no lo hayas subido todavía):

git commit --amend -m "Mensaje corregido"

Quiero deshacer el último commit pero conservar los cambios para rehacerlo bien:

git reset --soft HEAD~1

Estoy en medio de algo y necesito cambiar de rama ya, sin dejar un commit a medias:

git stash
git switch otra-rama
# y cuando vuelvas:
git stash pop

Una advertencia seria: ten mucho cuidado con git reset --hard. Ese sí borra tus cambios sin red de seguridad. Y nunca reescribas el historial (--amend, rebase) de commits que ya hayas subido y que otros puedan tener, porque les vas a romper el repositorio.

El .gitignore, desde el primer día

Hay cosas que nunca deben subirse: dependencias, archivos de configuración de tu editor, compilados y, sobre todo, credenciales.

node_modules/
target/
.env
.idea/
.vscode/
*.log

Crea el archivo .gitignore antes del primer commit. Si subes una contraseña o una clave de API por error, no basta con borrarla en el commit siguiente: queda en el historial y hay que considerarla comprometida.

Tres cosas que te harán quedar bien en las prácticas

• Nunca subas nada directamente a main. Si no sabes de qué rama partir, pregunta antes de tocar.
• Antes de abrir un pull request, revísate tú mismo el diff. La mitad de los comentarios que te van a poner los ves tú solo si lo miras antes.
• Mantén la rama enfocada. Una rama, un objetivo. No metas tres cosas distintas en el mismo pull request porque ibas pasando por ahí.

Para practicar

Crea un repositorio de pruebas y provócate un conflicto a propósito: haz dos ramas, edita la misma línea en las dos y fusiónalas. Resolver conflictos por primera vez con el código de tu empresa delante es innecesariamente estresante, y en un repo de juguete no pasa nada.

Si quieres ver cómo se usa todo esto en un entorno real, lo cuento en qué haces realmente en unas prácticas de DAW.