Guía básica de Git para el trabajo: config, remotes, pull y stash

¿Tu equipo sube cambios, tú bajas con git pull y de pronto todo explota con conflictos? Esta guía básica de Git te deja, en menos de 10 minutos, con la configuración lista, los conceptos de origin y remote claros, y un puñado de trucos (incluido git stash y git stash pop) para trabajar sin miedo a pisar el código de un compañero.

• Configura tu identidad con git config --global user.name y user.email antes de tu primer commit.
• remote es la URL del repositorio; origin es el alias que Git le pone por defecto cuando haces clone.
• Pull a menudo,Commitea pequeño, y usa ramas con prefijo (feat/, fix/) para reducir conflictos.
• Si tienes cambios sin commitear y necesitas un pull limpio, git stash los guarda; git stash pop los recupera.
• Si el pull avisa de conflictos, respira, lee los marcadores <<<<<<< y usa git status para guiarte.

1. Cómo configurar Git en tu PC (la primera vez)

Antes de tu primer commit necesitas tres cosas: tu nombre, tu email y, opcionalmente, tu editor y la rama por defecto.

# Identidad (obligatorio)
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

# Editor por defecto
git config --global core.editor "code --wait"   # VS Code
git config --global core.editor "vim"            # Vim

# Rama por defecto: main en vez de master
git config --global init.defaultBranch main

# Ver toda tu config
git config --list

Tip rápido: si trabajas en una sola máquina, con --global basta. Si alternas entre laptop personal y PC del trabajo, usa perfiles con includeIf en ~/.gitconfig para no mezclar commits laborales con personales.

2. Qué es origin y qué es un remote (y por qué importa)

Esta es la confusión más común al empezar. Resumido:

Comandos clave:

git remote -v                  # ver todos los remotes
git remote add origin <url>    # conectar un remoto
git remote rename origin prod  # renombrar alias
git remote remove upstream     # eliminar un remoto

Regla mental: origin no es nada mágico. Es solo el nombre que Git pone por defecto al primer clon. Puedes tener varios remotes (origin, staging, upstream) y cada uno apunta a su propia URL.

3. Buenas prácticas para no tener conflictos (la parte aburrida que te salva la vida)

Los conflictos no aparecen porque sí. Aparecen porque dos personas tocaron la misma línea. Las prácticas que de verdad los evitan:

1. Pull antes de empezar el día. 30 segundos que ahorran 30 minutos de merge.
2. Commits pequeños y con un solo propósito. Un commit = una idea. Más fácil de revertir y de entender.
3. Ramas con prefijo y vida corta. feat/login, fix/typo-footer. Se mergean en menos de 1-2 días.
4. No commitees archivos generados. Usa un .gitignore decente (compilados, node_modules, .env).
5. Comunica. "Voy a tocar el módulo de pagos" en el chat del equipo vale oro.
6. Actualiza tu rama con rebase (si tu equipo lo permite) en vez de merge para mantener un historial limpio.

4. Tienes cambios locales y alguien hizo push: cómo hacer pull sin llorar

Escenario clásico: llevas 2 horas editando, abres la terminal, intentas git pull y Git te dice no se puede, tienes cambios sin commitear. El flujo correcto es:

# Paso 1: mira qué tienes sin commitear
git status

# Paso 2: decide. ¿Lo guardo? ¿Lo desecho?
#   - Si lo quieres guardar → STASH (siguiente sección)
#   - Si no te importa perderlo → git checkout -- archivo

# Paso 3: baja los cambios remotos
git pull --rebase

# Paso 4: si hay conflictos, resuélvelos y continúa
git status                    # ver archivos en conflicto
# edita los archivos, busca los marcadores <<<<<<< ======= >>>>>>>
git add archivo-resuelto
git rebase --continue         # o git commit si hiciste merge normal

git pull vs git pull --rebase: el primero crea un commit de merge extra; el segundo reaplica tus commits encima del nuevo main. Para trabajo en equipo con historia limpia, prefiere rebase.

Checklist cuando el pull avisa de conflictos

• No entres en pánico ni fuerces un push --force.
• Lee los marcadores: <<<<<<< HEAD es tuyo, ======= es el remoto, >>>>>>> branch es del compañero.
• Borra los marcadores, deja el código correcto (a veces una mezcla de ambos).
• Compila y corre los tests antes de hacer git add.
• Cuando esté todo limpio, git rebase --continue o git commit.

5. git stash y git stash pop: tu bolsillo mágico

git stash es como una mochila invisible: guarda tus cambios sin commitear y deja tu working copy limpio para que puedas cambiar de rama o hacer un pull.

git stash                 # guarda cambios con mensaje por defecto
git stash save "wip: login"  # guarda con mensaje descriptivo (recomendado)
git stash list            # ver todos los stashes guardados
git stash show -p stash@{0}  # ver el contenido de un stash

Recuperar lo guardado: git stash pop

git stash pop             # recupera el último stash y lo BORRA de la lista
git stash apply stash@{0} # recupera un stash específico y lo MANTIENE en la lista

Diferencia clave: pop aplica y borra. apply aplica y conserva. Usa apply si no estás 100% seguro de querer soltarlo.

Trucos avanzados con stash

# Guardar solo algunos archivos
git stash push -m "wip parcial" -- archivo1.js archivo2.css

# Stash sin incluir archivos untracked (.env, builds, etc.)
git stash -u

# Crear una rama nueva a partir de un stash
git stash branch fix/login stash@{1}

# Borrar un stash concreto
git stash drop stash@{2}

# Limpiar todos los stashes
git stash clear

6. Errores comunes que cuestan horas (y cómo evitarlos)

• Commitear con email personal en repo de la empresa. Solución: perfiles con includeIf o un recordatorio al cambiar de carpeta.
• Hacer git push --force a main. Solución: pide a tu equipo activar branch protection en GitHub/GitLab.
• Olvidar el .gitignore y subir node_modules. Solución: usa gitignore.io o una plantilla del framework.
• git stash pop con conflictos y no saber qué hacer. Solución: si el pop falla, tus cambios siguen en la lista (git stash list). Nada se pierde.
• Mezclar merge y rebase en la misma rama. Solución: decide una estrategia por equipo y documéntala en el README.

Conclusión y siguiente paso

Con esta guía ya tienes lo mínimo para moverte con soltura: identidad, remotes, pull, y el parche salvavidas de git stash. Tu siguiente paso es simple: mañana, antes de empezar, ejecuta git pull --rebase y revisa git status. Hábitos pequeños, cero dramas.

Si quieres profundizar, las siguientes lecturas naturales son Gitflow (estrategia de ramas), cherry-pick (rescatar commits concretos) y interactive rebase (limpiar tu historia antes de PR).

FAQ

¿origin y remote son lo mismo?

No. remote es el concepto genérico (una URL conectada a tu repo). origin es solo el alias que Git pone por defecto al clonar. Puedes renombrarlo o tener varios.

¿Cómo sé si tendré conflictos antes de hacer git pull?

Ejecuta git fetch y luego git status. Git te dirá "Your branch is behind 'origin/main' by X commits" y si tu working copy está limpio. Aun así, los conflictos solo se ven al intentar el merge/rebase.

¿git stash pop puede borrar mis cambios?

No directamente. Si el pop genera conflictos, Git pausa y el stash se queda en la lista (git stash list). Solo desaparece tras aplicarse sin problemas. Si te arrepientes, puedes recuperarlo con git stash apply.

¿Cuándo usar git pull y cuándo git pull --rebase?

Usa git pull --rebase si quieres un historial lineal (recomendado en ramas personales). Usa git pull a secas en main o cuando trabajas con varios colaboradores en la misma rama larga.

¿Puedo tener varios remotes con el mismo alias?

No. Cada alias (origin, upstream, etc.) apunta a una sola URL. Si necesitas varias URLs, define alias distintos: origin, staging, prod.

¿git stash guarda los archivos nuevos (untracked)?

Por defecto no. Necesitas git stash -u o git stash --include-untracked para incluirlos. Muy útil para esos .env que generas por accidente.

Referencias externas

• Pro Git Book (oficial, gratis)
• GitHub Docs: Managing remote repositories