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

> Fuente: https://arbe.blog/guides/guia-basica-de-git-para-el-trabajo-config-remotes-pull-y-stash
> Publicado: 2026-07-10 · Actualizado: 2026-07-10
> Tags: GIT, GIT BÁSICO, GIT STASH, GIT PULL, CONFLICTOS GIT, GIT PARA PRINCIPIANTES, TRUCOS DE GIT, COMANDOS GIT

Aprende a configurar Git, diferenciar origin de remote, evitar conflictos y usar git stash con trucos rápidos para tu flujo de trabajo diario.

---

# 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:

| Concepto | Qué es | Ejemplo |
| --- | --- | --- |
| remote | Categoría: cualquier URL de repositorio Git conectada a tu copia local | origin, upstream, prod |
| origin | Nombre/alias que Git asigna por defecto al clonarlo | git remote -v → origin  git@github.com:equipo/app.git |
| upstream | Alias típico para el repo original cuando hiciste un fork | git remote add upstream ... |

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: &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD es tuyo, `=======` es el remoto, &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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](https://www.toptal.com/developers/gitignore) 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)](https://git-scm.com/book/es/v2)
- [GitHub Docs: Managing remote repositories](https://docs.github.com/es/repositories/working-with-files/managing-large-files/about-large-files-on-github)