🔄 Bajar y Subir Cambios: Repositorios Remotos y GitHub

Trabajar de forma aislada en tu computadora es solo el primer paso. El verdadero poder del control de versiones se despliega cuando sincronizas tu trabajo con repositorios remotos alojados en plataformas como GitHub, coordinando avances con otros desarrolladores.

En esta lección aprenderás:

1. La arquitectura entre repositorios locales y remotos (origin).
2. Cómo publicar tus commits en la nube con git push.
3. La diferencia fundamental entre git fetch y git pull.
4. Cómo configurar ramas de seguimiento (upstream tracking con -u).
5. El flujo de trabajo diario para descargar cambios de forma segura sin pisar tu trabajo.

---

🔁 Idea clave antes de empezar

Cuando usas Git normalmente hay dos copias del proyecto:

1️⃣ Tu computadora (repositorio local)
2️⃣ Internet (GitHub) (repositorio remoto, normalmente bajo el alias origin)

👉 Bajar cambios = traer lo que está en GitHub a tu PC (git pull)
👉 Subir cambios = enviar lo que confirmaste en tu PC a GitHub (git push)

---

📥 BAJAR CAMBIOS (pull)

🧠 ¿Cuándo necesitas bajar cambios?

• Al empezar a trabajar
• Cuando alguien más cambió el proyecto
• Cuando trabajas en varios dispositivos
• Para evitar conflictos

💡 Regla de oro:
👉 Antes de trabajar → baja cambios

---

🔹 Comando principal para bajar cambios

# Descarga los commits del remoto y los fusiona en la rama actual
git pull

¿Qué hace git pull?

Hace dos cosas automáticamente:

1. 📥 git fetch: Descarga los nuevos commits del repositorio remoto sin tocar tus archivos de trabajo.
2. 🔀 git merge: Los mezcla automáticamente con tu rama local activa.

---

📌 Ejemplo real (paso a paso)

Situación:

• Tu proyecto está en GitHub
• Un compañero cambió un archivo
• Tú quieres ese cambio en tu máquina

Pasos:

1️⃣ Entras a la carpeta del proyecto:

# Navegar a la carpeta de trabajo
cd mi-proyecto

2️⃣ Bajas los cambios:

# Traer y fusionar los cambios de GitHub
git pull

3️⃣ Git responde algo como:

Actualizando a1b2c3d..e4f5g6h
1 archivo modificado

🎉 Listo, ya tienes los cambios integrados.

---

❗ Error común al hacer pull

Si Git dice algo como:

error: Your local changes would be overwritten

👉 Significa:

Tienes cambios sin guardar (sin commit) en las mismas líneas que fueron modificadas en el remoto.

Solución:

Guarda tus cambios locales en un commit antes de traer lo ajeno:

# 1. Preparar tus cambios pendientes
git add .

# 2. Confirmar tu trabajo local
git commit -m "chore: guardo cambios antes del pull"

# 3. Ahora sí bajar y fusionar las novedades remotas
git pull

---

📤 SUBIR CAMBIOS (push)

🧠 ¿Cuándo necesitas subir cambios?

• Cuando terminaste una tarea

• Cuando quieres respaldar tu trabajo

• Cuando otros necesitan tus cambios

💡 Regla de oro:
👉 Después de trabajar → sube cambios

---

🔹 Flujo completo para subir cambios

⚠️ Esto es MUY importante, memorízalo:

Editar → add → commit → push

---

📌 Ejemplo completo de subir cambios

1️⃣ Modificas un archivo

Editas:

hola.txt

---

2️⃣ Revisas estado

# Consultar el archivo modificado en el working directory
git status

---

3️⃣ Agregas cambios

# Preparar las modificaciones en el staging area
git add .

---

4️⃣ Guardas cambios (commit)

# Crear el commit en la base de datos local
git commit -m "docs: actualizo el texto de saludo"

👉 Hasta aquí TODO ES LOCAL (solo en tu PC).

---

5️⃣ Subes a GitHub (push)

# Enviar los commits locales a la rama remota vinculada
git push

🎉 Ahora el cambio está en GitHub.

---

🌍 Primera vez que haces push (importante)

La primera vez Git necesita saber a dónde subir.

Se hace así:

# Subir al remoto origin y configurar seguimiento para que en el futuro baste con escribir 'git push'
git push -u origin main

¿Qué significa?

• origin → el alias del repositorio remoto (GitHub)
• main → la rama que estás subiendo
• -u → establece el upstream (rastreo) para que Git recuerde la asociación

Después de esto, en el día a día solo usarás:

# Subir cambios con seguimiento ya configurado
git push

---

🔄 Ciclo REAL de trabajo (vida real)

En un trabajo profesional diario SIEMPRE sigues este orden:

# 1. Al comenzar el día: traer las novedades del equipo
git pull

# 2. Trabajar, programar y probar localmente...

# 3. Preparar las modificaciones terminadas
git add .

# 4. Crear un commit con propósito único
git commit -m "feat: implemento cálculo de descuentos"

# 5. Publicar tus cambios en el repositorio compartido
git push

📌 Este ciclo te salva de problemas

---

⚠️ Conflictos al bajar cambios (explicado fácil)

Un conflicto pasa cuando:

• Tú cambiaste una línea
• Otra persona cambió la misma línea
• Ambos intentaron subir o bajar cambios

Git no sabe cuál de las dos versiones es la correcta 😵‍💫

Git te mostrará algo así:

<<<<<<< HEAD
Tu versión local
=======
Versión que viene de GitHub
>>>>>>> commit_remoto

Solución:

1. Abres el archivo con tu editor
2. Decides qué versión queda (o combinas ambas)
3. Borras los símbolos marcadores (<<<<<<<, =======, >>>>>>>)
4. Guardas el archivo limpio
5. Confirmas la resolución:

# 1. Marcar el archivo resuelto como preparado
git add .

# 2. Crear el commit de resolución
git commit -m "fix: resuelvo conflicto de merge con origin/main"

# 3. Subir la versión unificada a GitHub
git push

---

🧠 Comandos esenciales (resumen)

Acción	Comando
Ver estado	git status
Bajar cambios	git pull
Agregar cambios	git add .
Guardar cambios	git commit -m "mensaje"
Subir cambios	git push

---

❌ Errores típicos de principiantes

❌ Hacer push sin pull antes
❌ No hacer commits
❌ Mensajes como “cambios”
❌ Trabajar directo en main en equipo

---

🧠 Regla final (muy importante)

📥 Antes de trabajar → git pull
📤 Después de trabajar → git push