Tecnología · GUÍA PRÁCTICA
¿Git push dice “pre-receive hook declined”? Conserva el motivo remoto antes de reescribir commits
El resumen solo demuestra que el remoto rechazó una actualización antes de cambiar referencias; no identifica la regla. Guarda las líneas remotas, el mapa de refs y el dueño de la política, y corrige solo el límite probado.
“pre-receive hook declined” ubica una decisión remota, pero no explica su causa. La evidencia útil suele estar en las líneas remote anteriores, la actualización exacta de refs y la política del host.
Antes de resetear, forzar, borrar archivos o pedir que se debilite una regla, crea un registro redactado y dirige la reparación al contribuidor, mantenedor o administrador correcto.
1. Congela el rechazo exacto
Guarda toda la salida desde la primera línea remote: hasta cada ref rechazada. Registra URL saneada, transporte, origen local, destino remoto, cuenta efectiva, hora y versión de Git.
No empieces con reset, rebase, force push o borrado: podrías destruir la carga que identifica el commit, ruta, firma, objeto o ref que activó el rechazo.
2. Prueba dónde se tomó la decisión
Git define pre-receive como un hook del repositorio receptor que lee OID viejo, OID nuevo y nombre completo de ref antes de actualizar. Un estado no cero rechaza la recepción, así que omitir un hook local no sirve.
Separa pre-receive, el rechazo update por ref y un error post-receive. Conserva el motivo entre paréntesis y todos los mensajes remote.
3. Enruta la primera línea remote específica
Si el host nombra rama protegida, permiso, mensaje, email de autor, firma, archivo, tamaño, borrado de tag, secreto u objeto LFS ausente, verifica esa regla y su alcance. No sustituyas una causa popular.
Sin mensaje útil, el mantenedor revisa push rules y refs protegidas; el administrador revisa código, logs y timeout del hook. El contribuidor conserva la ref y sus OID anterior/nuevo.
4. Prueba la carga infractora antes de editar
Mapea cada origen y destino y compara el rango propuesto con la ref remota. Inspecciona metadata, rutas, tamaños, firmas y punteros LFS solo según la regla indicada; en push multi-ref, prueba cada ref.
Registra el objeto o control fallido y su dueño. Enmendar un commit, cambiar un permiso y reparar un hook son límites de responsabilidad distintos.
5. Repara lo mínimo y demuestra cierre
Cambia solo el límite probado y repite la misma actualización de ref. No debilites una regla compartida ni fuerces el push salvo que la política lo permita y reescribir historial sea intencional.
Comprueba que la ref remota apunta al OID esperado y que todas las refs fueron aceptadas. Si queda el mensaje genérico, vuelve a la primera línea remote no explicada o al log del servidor.
