Inicio » Cómo solucionar el error 'git push rejected non-fast-forward' de forma segura
Web y Código

Cómo solucionar el error 'git push rejected non-fast-forward' de forma segura

Lectura: 4 min Actualizado: 2026-07-27

El Diagnóstico Rápido

El error [rejected - non-fast-forward] o updates were rejected because the remote contains work that you do not have locally ocurre cuando intentas enviar commits locales a una rama remota en Git, pero el servidor remoto contiene commits más recientes que tu rama local no posee.

🔍 El Diagnóstico Rápido

Síntoma Causa Raíz Solución
error: failed to push some refs ... [rejected - non-fast-forward] El repositorio remoto tiene commits en la rama que no han sido integrados en tu copia local Ejecutar git pull --rebase origin <rama> para aplicar los cambios remotos antes del git push

🚀 Cómo solucionar el error paso a paso

Paso 1: Obtener e integrar las actualizaciones remotas con Rebase

En lugar de realizar un merge convencional que crea un commit de cruce desordenado, utiliza git pull --rebase para colocar tus nuevos commits locales encima del historial remoto actualizado:

BASH 
# Reemplaza 'main' por el nombre de tu rama (p. ej., dev o feature/login)
git pull --rebase origin main

Si prefieres hacerlo en dos pasos separados para inspeccionar las diferencias antes de fusionar:

BASH 
git fetch origin
git rebase origin/main

Paso 2: Resolver posibles conflictos de código

Si existen archivos modificados simultáneamente en local y remoto, Git pausará el proceso de rebase. Abre los archivos marcados con conflicto, resuelve las diferencias y ejecuta:

BASH 
# Marcar los archivos resueltos
git add .

# Continuar el proceso de rebase
git rebase --continue

Paso 3: Enviar tus cambios al servidor remoto

Una vez que tu rama local esté sincronizada y rebasada sobre el último commit remoto, realiza el envío de tus cambios de forma segura:

BASH 
git push origin main

Si reescribiste commits locales existentes y necesitas actualizar el remoto en una rama de trabajo personal, evita git push --force y utiliza la opción segura:

BASH 
git push origin main --force-with-lease

Consejo de Prevención

Prácticas de seguridad recomendadas:

  • Reglas de protección de ramas (Branch Protection Rules): Configura reglas en GitHub, GitLab o Bitbucket para impedir push directos y forzados en ramas principales como main o production.
  • Sincronizar antes de comenzar a programar: Adquiere el hábito de ejecutar git pull --rebase o git fetch al inicio de cada jornada de trabajo o antes de crear una nueva rama de características.
  • Preferir --force-with-lease sobre --force: La bandera --force-with-lease verifica si otra persona subió cambios al remoto entre tanto antes de sobrescribir el historial.