Tecnología · GUÍA PRÁCTICA
¿Git fatal: bad object? Demuestra el ref, el objeto y el límite del repositorio antes de borrar
Conserva el trabajo local, resuelve el ref exacto, prueba el objeto, clasifica el historial shallow o parcial y repara solo la capa que la evidencia demuestra rota.
`fatal: bad object` no identifica una sola reparación. Git puede resolver un nombre hacia un objeto ausente, encontrar un ref inválido, cruzar un límite shallow o parcial intencional, abrir otro repositorio o detectar daño real.
Conserva el árbol de trabajo y los metadatos antes de cambiar nada. Después demuestra el ref exacto, el ID, el tipo de objeto y el límite de alcanzabilidad. Una reparación segura cambia la capa mínima probada y conserva una vía de recuperación.
Conserva el trabajo antes de ejecutar reparaciones
Copia el árbol y los metadatos antes de checkout, reset, gc, prune, repack o borrar refs. Registra status, raíz, directorio Git, remotos, worktrees y todos los refs; elimina credenciales pero conserva nombres e IDs.
En repositorios grandes conserva al menos archivos sin commit, HEAD, refs, reflogs, shallow, alternates y configuración partial. Usa un clone nuevo para comparar, no para reemplazar antes de revisar trabajo local.
Resuelve el nombre exacto y prueba el objeto exacto
Usa literalmente el valor tras bad object. Si es un ref, verifícalo con show-ref, for-each-ref y rev-parse; prueba el ID con cat-file -e y su tipo con cat-file -t. Registra qué parte falla.
Demuestra también qué repositorio y worktree usó el proceso. Editores, hooks, servicios y CI pueden ejecutar con otro directorio o GIT_DIR; reproduce el entorno original.
Interpreta fsck sin llamar pérdida a cada línea
Ejecuta git fsck --full sobre la copia. Un objeto missing, puntero inválido, hash mismatch o archivo corrupto requiere acción. dangling significa que el objeto existe pero no es alcanzable desde refs normales y puede ayudar a recuperar.
Relaciona el primer error útil con el ref o enlace padre exacto. Si solo un ref local prescindible apunta a un objeto ausente, un update-ref -d dirigido puede ser adecuado; nunca lo amplíes a un borrado masivo.
Separa límites intencionales de datos ausentes
Comprueba .git/shallow, profundidad de CI, filtros partial, remotos promisor, alternates y submódulos. Una raíz shallow es intencional; actions/checkout obtiene un commit por defecto.
Solo después de confirmar remoto e historial, profundiza o trae el ref exacto. fetch-depth: 0 pide el historial completo, aunque una profundidad menor o fetch dirigido puede bastar.
Elige la reparación mínima y demuestra el cierre
Reorienta un ref simbólico o remoto obsoleto hacia una rama verificada o borra solo ese ref probado. Profundiza clones delgados; recupera objetos alcanzables realmente ausentes desde un clone fiable, copia o almacén alternativo.
Repite el comando original y vuelve a comprobar ref, objeto y fsck. Confirma el trabajo local y conserva la copia dañada hasta que un clone nuevo o backup pruebe una ruta de recuperación independiente.
