Hacer push — qué es, cómo funciona git push y cuándo se necesita

Qué es un push en Git

Git push es un comando que transfiere commits de un repositorio local a uno remoto. A diferencia de un commit, que guarda los cambios solo en la máquina local del desarrollador, un push publica esos cambios para todo el equipo. Push es un paso obligatorio antes de crear un Pull Request y el despliegue.

La arquitectura de Git asume que cada desarrollador trabaja en su propio repositorio local. Los commits se crean localmente y se acumulan hasta que el desarrollador decide hacer push. Esto proporciona libertad: puedes hacer muchos commits locales, experimentar y reescribir el historial sin afectar a los compañeros.

# Hacer push al remoto origin, rama main
git push origin main

# Enviar la rama actual al remoto con upstream
git push -u origin feature/new-dashboard

# Enviar todas las ramas con nombres coincidentes
git push --all origin

# Force push con lease (push forzado seguro)
git push --force-with-lease

Después de un push, el repositorio remoto actualiza las refs (referencias a ramas) para que apunten a los nuevos commits. Otros desarrolladores pueden obtener estos cambios mediante git pull o git fetch. Este intercambio de commits constituye la base del desarrollo colaborativo.

Cómo funciona git push

El comando git push compara las ramas locales y remotas y transfiere solo los commits faltantes. Git no reenvía todos los archivos — transfiere solo el delta, lo que hace que el push sea rápido incluso para repositorios grandes. Protocolo Git utiliza transferencia inteligente, que minimiza la cantidad de datos transmitidos.

Si la rama remota contiene commits que no están presentes localmente, el push será rechazado. Este es un mecanismo de protección que evita la pérdida de cambios. En tal situación, el desarrollador debe ejecutar primero git pull, fusionar los cambios y solo entonces hacer push nuevamente. Una alternativa es force push, que sobrescribe la rama remota, pero debe usarse con precaución.

Comprender los repositorios remotos es clave para un push adecuado. Normalmente, origin es el nombre del repositorio remoto por defecto. El comando git remote -v muestra la lista de repositorios remotos y sus URL. Puedes agregar varios remotes (por ejemplo, origin para el repositorio principal y upstream para un fork).

Cuándo hacer push de cambios

La regla principal: hacer push después de cada etapa de trabajo lógicamente completada. Si un desarrollador ha terminado una tarea o parte de ella — es hora de hacer push. Sin embargo, no se recomienda hacer push de trabajo incompleto que rompa la compilación. Compilación sin errores es el requisito mínimo para hacer push a cualquier rama.

En el desarrollo en equipo se adopta el siguiente ritmo: por la mañana — git pull para obtener los cambios de los compañeros, durante el día — varios commits y uno o dos pushes, por la tarde — un push final de todas las tareas completadas. Cuanto más a menudo un desarrollador hace push, menor es el riesgo de conflictos de fusión y más transparente es el progreso del trabajo.

• Después de completar una tarea — hacer commit y push de la solución final a la rama feature
• Antes de irse — hacer push del trabajo incompleto a una rama feature (no a main!)
• Antes de crear un PR — asegurarse de que todos los commits estén enviados y disponibles para revisión
• Después de rebase — hacer push con --force-with-lease a tu rama feature

Reglas de push seguro

El push seguro es un conjunto de reglas que evitan la pérdida de datos y conflictos en el equipo. La primera y principal regla: nunca hacer push directamente a la rama main o master si el proyecto no tiene configurado el despliegue directo. En los equipos modernos, la protección de la rama main se configura a nivel de protección de rama de GitHub.

La segunda regla: sincronizar con la rama remota antes de hacer push. Ejecuta git pull --rebase para evitar commits de fusión al unir. Esto simplifica el historial y lo hace lineal. Si un push es rechazado — no uses force push simple, primero averigua qué commits aparecieron en la rama remota.

La tercera regla: configurar hooks pre-push que ejecuten automáticamente pruebas y linters antes del envío. Si las pruebas fallan — el push se bloquea. Estos hooks se configuran mediante Husky o Git hooks (archivo pre-push en .git/hooks).

La cuarta regla: no hacer push de archivos binarios grandes. Git no está diseñado para almacenar artefactos binarios — inflan el repositorio y ralentizan las operaciones. Para archivos grandes, usa Git LFS (Large File Storage). Si un binario ya ha sido enviado y está en el historial, debe eliminarse mediante git filter-branch.

Qué hacer si el push falla

La razón más común de un push fallido es que la rama remota contiene commits que no están presentes localmente. Esto ocurre cuando otro desarrollador ha hecho push de sus cambios a la misma rama. Solución: ejecuta git pull, resuelve los conflictos y vuelve a hacer push.

# Push rechazado — haz fetch y rebase primero
git fetch origin
git rebase origin/main
# Resuelve los conflictos, luego:
git push --force-with-lease

# O simplemente fusiona los cambios remotos
git pull origin main
git push

La segunda razón — falta de permisos de escritura en la rama. Si la rama main está protegida por reglas de protección de rama, los pushes directos están prohibidos. Solución: hacer push a una rama feature y crear un Pull Request. La configuración de protección generalmente se administra a través de configuración de GitHub o ramas protegidas de GitLab.

La tercera razón — problemas de autenticación. Credenciales desactualizadas, cambio a SSH o token de acceso personal modificado. Solución: verifica la URL remota (git remote -v) y actualiza las credenciales. Desde 2021, GitHub eliminó la autenticación por contraseña para HTTPS — usa un token personal o clave SSH.