📤 Push, Pull y Cloning en GitHub

Bienvenido a esta lección fundamental donde aprenderás los tres comandos esenciales para sincronizar tu trabajo local con GitHub: push, pull y clone. Dominar estos comandos es absolutamente crítico para trabajar eficientemente en equipo.

🔽 ¿Qué es Clonar un Repositorio?

Cuando quieres trabajar en un proyecto que ya existe en GitHub, necesitas clonarlo a tu máquina local. El comando git clone descarga todo el repositorio completo, incluyendo su historial de commits, ramas y archivos.

git clone https://github.com/usuario/nombre-repositorio.git

Este comando crea automáticamente:

• Una carpeta con el nombre del repositorio
• Una conexión remota llamada origin apuntando al repositorio de GitHub
• Una copia completa de todo el código y su historial

📤 Empujando Cambios con Push

Una vez que has hecho cambios localmente y los has confirmado con git commit, necesitas subirlos a GitHub para que otros miembros del equipo puedan verlos. Esto se hace con git push.

1. Haz cambios en tus archivos usando tu editor de código favorito.
2. Prepara los cambios: git add archivo-modificado.js o git add . para todos los archivos.
3. Crea un commit: git commit -m "Mensaje descriptivo del cambio"
4. Envía los cambios: git push origin nombre-rama

# Ejemplo completo de push
git add .
git commit -m "Agregar validación de formulario de registro"
git push origin develop

📥 Trayendo Cambios con Pull

Cuando trabajas en equipo, otros desarrolladores estarán subiendo cambios constantemente. Para mantener tu código actualizado con lo último del repositorio remoto, usas git pull.

git pull origin main

El comando git pull hace dos cosas simultáneamente:

1. Fetch: Descarga los cambios del remoto
2. Merge: Integra esos cambios con tu rama actual

⚙️ Fetch vs Pull: ¿Cuál Usar?

Existe una diferencia importante entre estos dos comandos:

🔗 Entendiendo los Remotes

Un remote es una conexión a un repositorio en otro lugar (generalmente GitHub). Cuando clonas un repositorio, Git automáticamente crea un remote llamado origin que apunta al repositorio original.

Puedes ver tus remotes con:

git remote -v

La salida típica sería:

origin  https://github.com/usuario/repo.git (fetch)
origin  https://github.com/usuario/repo.git (push)

# Añadir un remote adicional
git remote add upstream https://github.com/proyecto-original/repo.git

# Sincronizar desde el repositorio original
git fetch upstream
git merge upstream/main

🌿 Empujando Ramas Nuevas

Cuando creas una nueva rama local y quieres subirla a GitHub por primera vez, necesitas especificarla:

# Crear y cambiar a nueva rama
git checkout -b feature/nueva-funcionalidad

# Hacer cambios y commits...

# Empujar la nueva rama por primera vez
git push -u origin feature/nueva-funcionalidad

El flag -u (o --set-upstream) establece una relación de seguimiento entre tu rama local y la rama remota. Después de esto, simplemente puedes usar git push sin especificar origin ni el nombre de la rama.

"La primera vez que empujas una rama, usa -u. Es como presentar tu rama local al mundo—después podrán encontrarse fácilmente."

⚠️ Manejo de Conflictos

A veces, cuando haces git pull, Git no puede fusionar automáticamente los cambios porque tú y otro desarrollador editaron las mismas líneas. Esto se llama conflicto de fusión.

1. Git te avisa sobre los archivos en conflicto con el mensaje: "Merge conflict in archivo.js"
2. Abre el archivo y busca los marcadores de conflicto: <<<<<<< HEAD, =======, >>>>>>>
3. Decide qué código mantener: el tuyo, el del remoto, o una combinación de ambos
4. Elimina los marcadores de conflicto
5. Guarda, añade y haz commit: git add . y git commit

📊 Flujo de Trabajo Típico en Equipo

Este es el ciclo de trabajo diario que seguirás la mayoría de las veces:

# Al comenzar el día
git pull origin main           # Actualizar con últimos cambios

git checkout -b feature/tarea-123   # Crear rama para tu trabajo

# Durante el día
# ... hacer cambios en código ...
git add .
git commit -m "Implementar lógica de autenticación"

# Al terminar
git push -u origin feature/tarea-123   # Subir rama por primera vez
# Crear Pull Request en GitHub

🎯 Buenas Prácticas

• Commits frecuentes y pequeños: Haz commit de tus cambios regularmente, no esperes a terminar todo el proyecto.
• Mensajes descriptivos: Escribe mensajes que expliquen el por qué, no solo el qué.
• Pull antes de push: Siempre intenta hacer pull antes de push para minimizar conflictos.
• Ramas para todo: Evita hacer push directamente a main. Usa ramas feature.

# Push a la rama actual sin especificar origen
# (funciona si ya hiciste push con -u antes)
git push

# Pull de la rama que seguimiento establecida
git pull

# Push todas las ramas
git push --all origin

git config --global pull.rebase true

🔒 Permisos y Autenticación

Para hacer push a repositorios en GitHub, necesitas autenticarte. GitHub recomienda usar:

• GitHub CLI: gh auth login
• Token de acceso personal (PAT): Generado desde GitHub → Settings → Developer settings
• SSH: Usando claves SSH en lugar de HTTPS

ssh-keygen -t ed25519 -C "[email protected]"
gh ssh-key add ~/.ssh/id_ed25519.pub

📝 Resumen de Comandos

🎓 Conclusión

Ahora tienes las herramientas fundamentales para sincronizar tu trabajo entre tu computadora y GitHub. Recuerda:

• Clone para comenzar—obtén el proyecto a tu máquina
• Pull para mantenerte actualizado—trae los cambios del equipo
• Push para compartir—envía tu trabajo al mundo

En la siguiente lección aprenderás sobre Pull Requests, el mecanismo principal para proponer y revisar cambios en equipos que usan GitHub. ¡Sigue adelante!