Casi todos los que empezamos con Git rompimos un repositorio al menos una vez. La diferencia entre un junior y un senior no es que no se equivoquen, es que ya saben cómo salir del lío. Acá van los errores más comunes y cómo evitarlos.
1. Mensajes de commit sin sentido
«fix», «cambios», «asd». Un mensaje de commit debería explicar el por qué, no solo el qué. Convención simple: tipo: descripción corta (ej. fix: corrige validación de email en registro).
2. Trabajar directo sobre main
Sin darse cuenta, muchos junior programan y commitean directo en la rama principal. Un error ahí puede romper el código que todo el equipo usa. Solución: crear una rama por feature o fix, por chica que sea la tarea.
3. Hacer git push --force sin entender qué hace
Sobreescribe el historial remoto y puede borrar el trabajo de otros. Si necesitás forzar un push, usa --force-with-lease, que al menos verifica que no estés pisando cambios ajenos.
4. No hacer pull antes de empezar a trabajar
Empezar a programar sobre una versión vieja del código genera conflictos innecesarios. Hábito simple: git pull apenas te sentás a trabajar, siempre.
5. Resolver conflictos borrando el código del otro
Ante un conflicto, la tentación es quedarse con «tu» versión y borrar la otra sin leerla. Eso puede eliminar lógica importante. Leé ambas versiones, entendé qué hace cada una, y combiná si hace falta.
6. No usar .gitignore
Subir carpetas como node_modules, archivos .env con credenciales, o binarios pesados infla el repositorio y puede filtrar secretos. Configurá el .gitignore desde el primer commit del proyecto.
7. No entender la diferencia entre merge y rebase
Usarlos sin saber qué hace cada uno genera historiales confusos o duplicados. Regla simple para empezar: merge para integrar ramas compartidas, rebase solo en tu rama personal antes de compartirla.
La buena noticia: ningún error de esta lista es irreversible si lo detectás a tiempo. Git guarda casi todo en su historial interno (git reflog es tu mejor amigo en un momento de pánico).
