Pré-vol GitHub
Pousser un nouveau dépôt échoue de quelques manières ennuyeuses et répétitives, et les messages d'erreur pointent vers la mauvaise chose. src refspec main does not match any ressemble à un problème de branche mais signifie généralement qu'il n'y a aucun commit. Un push qui réussit silencieusement sous un compte professionnel semble identique à un push correct. Cette compétence détecte ces problèmes avant que l'utilisateur ne perde du temps avec un push.
La règle directrice : diagnostiquer, ne pas muter. Signaler les résultats et fournir des commandes de correction à copier-coller. L'utilisateur les exécute. Les gens conservent plusieurs comptes précisément parce qu'ils se soucient de celui qui agit, donc exécuter silencieusement git config ou git remote set-url à leur place est exactement le mauvais réflexe ici.
Exécution
bash <skill-dir>/scripts/preflight.sh [chemin-dépôt] [nom-distant]
Les deux arguments sont facultatifs — ils par défaut au répertoire courant et à origin. Le script ne fait que lire : git config --get, ls-remote, ssh -T, push --dry-run. Il n'écrit jamais.
Si le script ne peut pas s'exécuter pour une raison quelconque, les vérifications ci-dessous sont chacune d'une seule ligne ; exécutez-les directement et interprétez-les de la même manière.
Signification des vérifications
Le script affiche des lignes PASS / WARN / FAIL. L'interprétation compte plus que le résultat brut, alors traduisez plutôt que de coller :
Dépôt / fichiers / commits. Un répertoire vide ou un dépôt sans commits produit src refspec <branche> does not match any au moment du push. Git ne peut pas construire un commit à partir de rien. C'est la cause la plus fréquente d'un premier push échoué, donc commencez par là lorsqu'elle se déclenche.
Branche. Un git init frais peut atterrir sur master alors que le distant attend main. Renommer est sûr après le premier commit (git branch -M main) — sur une branche non née, il n'y a encore rien à renommer, c'est pourquoi ordonner les commandes dans le mauvais ordre gaspille un cycle.
URL distante effective. Utile à connaître précisément, car il est facile de vérifier cela de manière incorrecte : git remote get-url développe déjà url.<base>.insteadOf, tout comme git ls-remote --get-url. Comparer ces deux-là ne détecte donc rien. La valeur brute ne subsiste que dans git config --get remote.<name>.url, donc c'est ce que le script compare à git remote get-url --push (la forme --push couvre en plus pushurl et pushInsteadOf, qui sont ce qu'un push utilise réellement). Lorsque les deux diffèrent, l'URL configurée par l'utilisateur n'est pas celle que Git contactera. Le piège classique est un url."https://github.com/".insteadOf = [email protected]: global, qui redirige silencieusement SSH vers HTTPS et donc vers le compte détenu par l'assistant d'identification — souvent pas celui que l'utilisateur souhaitait. Signalez toujours l'URL effective et signalez explicitement la différence.
Compte d'authentification. Pour SSH, le script résout l'hôte via ssh -G (afin que les alias d'hôte comme github-personal soient suivis jusqu'à leur nom d'hôte et clé réels) puis interroge directement GitHub avec ssh -T. GitHub répond Hi <utilisateur>! et se termine avec 1 — le code de sortie 1 est le cas de succès ici, pas un échec. Pour HTTPS, il lit le compte gh actif. Comparez ce compte avec le segment propriétaire de l'URL : une discordance signifie que le push générera une erreur 403 ou atterrira dans le mauvais espace de noms.
Identité de commit. user.email hérité de la configuration globale est l'échec silencieux. Le push s'authentifie en tant qu'un compte tandis que chaque commit est signé sous une autre adresse — et le corriger plus tard signifie modifier ou réécrire l'historique. Traitez une identité de portée globale sur un dépôt dont le distant appartient à un propriétaire différent comme un WARN à signaler de manière proéminente, même si rien n'est techniquement cassé pour le moment.
État distant. Un distant vide signifie que le premier push est propre. Des références existantes signifient qu'un push simple sera rejeté comme non-fast-forward et que l'utilisateur doit d'abord faire pull/rebase — dites-le avant qu'il ne subisse le rejet. Une erreur ici signifie généralement que le dépôt n'existe pas ou que le compte n'a pas les droits d'accès ; GitHub signale délibérément les deux comme "introuvable", donc proposez les deux explications plutôt que de deviner.
Push à sec. Possible seulement une fois qu'un commit existe. C'est la véritable vérification de bout en bout — elle teste l'authentification et la négociation de références sans écrire. Notez son angle mort : elle ne détecte pas les rejets côté serveur comme GH007 (confidentialité des e-mails), car ceux-ci sont évalués lors de la réception réelle.
Rapport
Donnez un petit tableau des vérifications, puis — seulement pour les éléments qui ont échoué ou généré un avertissement — les commandes exactes pour les corriger, dans un ordre exécutable. Ne déversez pas les vérifications réussies en prose ; l'utilisateur veut savoir ce qui ne va pas et quoi taper.
Lorsque l'identité doit être définie, préférez la configuration locale du dépôt à la modification de la configuration globale, car tout l'enjeu est que ce dépôt diffère de la valeur par défaut de la machine :
git config user.name "<compte>"
git config user.email "<email>"
Si plusieurs dépôts nécessitent le même traitement, mentionnez includeIf comme correctif durable :
[includeIf "gitdir:~/personnel/"]
path = ~/.gitconfig-personnel
Et si le push est rejeté avec GH007, pointez vers l'adresse @users.noreply.github.com depuis GitHub → Paramètres → E-mails plutôt que de deviner une adresse personnelle — les commentaires de clés et la configuration locale sont des étiquettes, pas une preuve de ce que le compte accepte.