Git o morir: cómo no perder tu código ni tu dignidad

La escena: 11:47 pm. Mañana hay demo. Tu laptop viejita ya suena como microondas, el ventilador anda en modo turbina y tú jurabas que “sí guardé ese archivo”.

Le das Ctrl+Z como si fuera respawn infinito… pero no. Y para rematar, hiciste cambios directo en main, algo se rompió y te cae el mensaje: “súbelo al repo para revisarlo”.

Ahí es donde Git deja de ser “herramienta de dev mamador” y se vuelve cinturón de seguridad. A veces también terapia, no nos hagamos.

Qué vas a aprender

• Usar Git sin vivir con miedo: init/clone, add, commit, push, pull.
• Un workflow realista con ramas: feature branches y PRs sin drama.
• Cómo no perder trabajo: commits con intención, mensajes decentes y backups reales.
• Cómo rescatarte cuando ya la regaste: reflog, restore, reset (sin incendiar todo).
• Decisiones prácticas: cuándo merge, cuándo rebase (y cuándo mejor ni le muevas).

Contexto práctico: por qué Git salva jales (y relaciones)

Git no es nomás “para trabajar en equipo”. También es para trabajar contigo mismo dentro de dos semanas, cuando ya no te acuerdas por qué ese if está al revés.

Dos realidades bien comunes:

1. El “pásame el ZIP” por WhatsApp. Sirve… hasta que existen proyecto_final_v3_ahora_si.zip, proyecto_final_v3_ahora_si_2.zip y el “final” que ya no compila. Git te evita ese multiverso.

2. La chamba con internet intermitente. Café, cowork, datos del cel, la vida. Con Git trabajas local, haces commits offline y haces push cuando haya señal. El repo es tu bitácora.

Regla de oro: Git no te quita bugs. Te quita el pánico.

Paso a paso: el workflow que sí aguanta producción (y tareas de la escuela)

1) Setup mínimo (sin caer en la madriguera)

Configura tu identidad una vez:

git config --global user.name "Tu Nombre"
git config --global user.email "tuemail@dominio.com"

Checa que sí quedó:

git config --global --list

Si estás en Windows y te sale el tema de CRLF/LF y no tienes ganas de una guerra absurda de saltos de línea, en equipos mixtos suele funcionar:

git config --global core.autocrlf true

No es magia, pero te ahorra talacha.

2) Crear repo o clonar

Si ya existe en GitHub/GitLab/Bitbucket:

git clone https://github.com/tu-org/tu-repo.git
cd tu-repo

Si es tu proyecto local y lo quieres versionar:

cd mi-proyecto
git init

Pon .gitignore desde el día 1. Neta.

• No subas node_modules
• No subas builds (dist/, build/)
• No subas .env (ni “nomás tantito”) — eso se vuelve incidente de production en corto

Ejemplo para Node:

node_modules/
dist/
.env
.DS_Store

3) Tu primer commit (el checkpoint)

Git funciona mejor si lo tratas como videojuego: checkpoint frecuente, no “hasta que quede perfecto”. Porque cuando el jefe te pide un cambio “rápido” a las 6:50 pm, lo último que necesitas es miedo a tocar algo.

Flujo básico:

git status
# ves qué cambió

git add .
# preparas lo que sí quieres commitear

git commit -m "chore: proyecto base con .gitignore"

Tip de vida real: si vas empezando, no hagas git add . en automático todo el tiempo. Mejor selecciona archivos:

git add archivo1.js archivo2.css
git commit -m "feat: landing inicial"

Así no subes por accidente tu .env con el token de production (sí pasa… y sí duele).

4) Conecta remoto y sube tu código

Si creaste el repo en GitHub, conecta el remoto:

git remote add origin https://github.com/tu-org/tu-repo.git

Sube tu rama (si estás en main):

git push -u origin main

Si tu rama se llama master y quieres alinearte a lo estándar de la mayoría:

git branch -M main
git push -u origin main

5) Trabaja como adulto funcional: ramas por tarea

Regla práctica: no trabajes directo en main. Ni aunque “nomás sea un cambio chiquito”. Esos son los que tumban el deploy.

Crea una rama para tu cambio:

git checkout -b feat/login

Haz commits pequeños (de esos que sí se pueden revisar):

git add .
git commit -m "feat: pantalla de login"

git add .
git commit -m "fix: valida campos vacios"

Sube tu rama:

git push -u origin feat/login

Abres PR (pull request) y listo. Aunque trabajes solo, el PR sirve como “alto”: revisas con cabeza fría antes de mezclar. Es el mini ritual que evita bugs por prisa.

6) Mantén tu rama al día sin hacer un Frankenstein

Antes de seguir, actualiza main:

git checkout main
git pull

Regresa a tu rama:

git checkout feat/login

Opción A (simple y segura): merge main a tu rama:

git merge main

Opción B (historial más clean, pero más delicado): rebase:

git rebase main

Tradeoff sin romanticismo:

• Merge: deja cicatrices en el historial, pero es difícil romper algo.
• Rebase: historial bonito, pero si no entiendes qué reescribe y ya publicaste la rama, puedes armar un desastre y luego andas pidiendo rollback.

Si estás en equipo y no dominas rebase: usa merge. Tu dignidad vale más que un grafo perfecto.

7) Kit de supervivencia: comandos para cuando ya la regaste

“Borré cambios sin querer”

Si todavía no haces commit y quieres regresar un archivo a como estaba:

git restore archivo.js

Si quieres sacar algo del staging (lo agregaste con add pero aún no commiteas):

git restore --staged archivo.js

“Hice un commit, pero el mensaje está feo / olvidé un archivo”

Si es el commit más reciente:

git commit --amend

Esto reescribe el último commit. Ojo: si ya hiciste push, lo más probable es que termines forzando (--force-with-lease) y eso puede meterle ruido a todo el equipo.

“Hice commit y ahora todo está roto. Quiero volver al estado anterior.”

Si quieres mover la rama a un commit anterior y tirar los cambios:

git reset --hard <hash>

Esto es motosierra. Úsalo cuando estés seguro y, si puedes, primero respalda lo que traes.

Si quieres volver atrás sin perder tu trabajo (dejar cambios como “no commiteados”):

git reset --soft <hash>

“No sé qué hice, pero sé que Git lo sabía hace 20 minutos”

Tu compa se llama reflog:

git reflog

Ahí ves movimientos recientes. Puedes regresar a un estado anterior aunque “parezca perdido”:

git reset --hard HEAD@{3}

reflog es la diferencia entre “ya valió” y “ok, lo arreglo en 5 minutos”.

Screenshots sugeridos

• git status mostrando archivos modified/untracked.
• Vista de ramas en tu editor (VS Code Source Control) con main y feat/login.
• Pantalla de GitHub con PR abierto y checklist de revisión.
• Ejemplo de conflicto de merge y el editor mostrando los marcadores <<<<<<<.
• Salida de git reflog y el “regreso” con reset --hard HEAD@{n}.

Errores comunes + solución (los que sí pasan)

Error 1: Trabajar directo en main

Síntoma: tu main tiene 15 commits de “fix, fix2, ahora sí” y nadie sabe qué se mezcló.

Solución: usa ramas por tarea y PR. Si ya te pasó, crea una rama desde tu estado actual y acomoda el workflow:

git checkout -b rescue/mis-cambios

Deja main estable (si existe un commit bueno) y luego haces PR desde tu rama.

Error 2: Commits gigantes de 200 archivos

Síntoma: revisar un PR se siente como leer la Biblia en diff.

Solución: commitea por intención: “agrega endpoint”, “ajusta UI”, “corrige validación”. Usa git add -p para escoger pedacitos:

git add -p

Error 3: Conflictos de merge que nadie entiende

Síntoma: aparecen <<<<<<< HEAD y te dan ganas de renunciar.

Solución:

1. No entres en pánico.
2. Abre el archivo y decide qué versión se queda (con lógica, no con coraje).
3. Corre tests o mínimo levanta el proyecto.
4. Haz commit del merge.

Dato que te ahorra horas: conflictos bajan un montón con commits chicos y ramas que viven poco.

Error 4: Subir secretos al repo

Síntoma: subiste .env, una key o un token; ya lo vio medio mundo.

Solución (modo defensivo):

• Rota/invalida la key ya, antes de “arreglar Git”.
• Quita el archivo y agrégalo a .gitignore.
• Si fue a un repo público, considera limpiar historial con git filter-repo y asume que el secreto ya se filtró.

Error 5: “Mi push fue rechazado”

Síntoma: rejected (non-fast-forward).

Solución: alguien subió cambios antes. Trae y mezcla:

git pull --rebase

Si no dominas rebase (o vienes con sueño y deadline), usa:

git pull

Y luego push.

Checklist final (para no perder el hilo)

• Tengo .gitignore decente y no versiono node_modules/.env.
• No trabajo directo en main; uso ramas por tarea.
• Commits pequeños con mensajes claros (qué y por qué).
• Antes de abrir PR, jalo cambios de main y resuelvo conflictos local.
• Sé usar restore para deshacer sin pánico.
• Sé usar reflog para rescate cuando “ya valió”.
• Mis PRs tienen descripción y pasos para probar (aunque sea “npm test”).

FAQ

1) ¿Cada cuánto hago commit?

Cuando completes una unidad con sentido: un endpoint, un componente, una corrección. Si no lo puedes describir en una frase, está muy grande.

2) ¿Qué pongo en el mensaje del commit?

Algo como: feat:, fix:, chore:, refactor: y una frase humana. Ejemplo: fix: evita crash si usuario viene null.

3) ¿Merge o rebase?

Si estás empezando o estás en equipo con banda de distintos niveles: merge. Rebase cuando entiendas bien qué reescribe y cuando tu equipo lo tenga como estándar.

4) ¿GitHub Desktop o puro terminal?

Los dos jalan. Terminal te da control y te enseña mejor qué está pasando. GUI te reduce fricción. Regla personal: aprende lo básico en terminal; usa GUI cuando estés cansado y haya deadline.

5) ¿Qué hago si ya subí un commit con un secreto?

Asume compromiso. Rota el secreto, elimina el archivo, y si hace falta limpia historial. Aunque borres el commit, el secreto pudo haber sido copiado.

Siguiente episodio

Git ya te dio memoria y cinturón de seguridad. Lo que sigue es pelearte con tu propia máquina: permisos, paths, variables de entorno y ese bug clásico de “en mi compu sí jala”.