Was macht GitHub Preflight?
Das Pushen eines neuen Repos schlägt auf eine Handvoll langweiliger, sich wiederholender Arten fehl, und die Fehlermeldungen zeigen auf die falsche Ursache. src refspec main does not match any klingt nach einem Branch-Problem, bedeutet aber meist, dass es keine Commits gibt. Ein Push, der stillschweigend unter einem Arbeitskonto erfolgreich ist, sieht identisch aus wie ein korrekt durchgeführter Push. Dieses Skill findet diese Probleme, bevor der Benutzer einen Push darauf verschwendet.
Die Leitregel: Diagnostizieren, nicht mutieren. Ergebnisse melden und kopierbare Befehle zur Behebung zurückgeben. Der Benutzer führt sie aus. Leute führen mehrere Kontante gerade deshalb, weil ihnen wichtig ist, welches handelt. Daher ist es genau der falsche Instinkt, hier stillschweigend git config oder git remote set-url in ihrem Namen auszuführen.
Ausführung
bash <skill-dir>/scripts/preflight.sh [repo-pfad] [remote-name]
Beide Argumente sind optional – sie standardmäßig auf das aktuelle Verzeichnis und origin. Das Skript liest nur: git config --get, ls-remote, ssh -T, push --dry-run. Es schreibt nie.
Wenn das Skript aus irgendeinem Grund nicht ausgeführt werden kann, sind die untenstehenden Prüfungen jeweils ein Einzeiler; führen Sie sie direkt aus und interpretieren Sie sie auf dieselbe Weise.
Was die Prüfungen bedeuten
Das Skript gibt Zeilen mit PASS / WARN / FAIL aus. Die Interpretation ist wichtiger als die rohe Ausgabe, also übersetzen Sie sie anstatt sie einfach einzufügen:
Repo / Dateien / Commits. Ein leeres Verzeichnis oder ein Repo ohne Commits produziert beim Push src refspec <branch> does not match any. Git kann keinen Commit aus dem Nichts erstellen. Dies ist die häufigste Ursache für einen fehlgeschlagenen ersten Push, also führen Sie damit an, wenn es auftritt.
Branch. Ein frisches git init landet möglicherweise auf master, während das Remote main erwartet. Das Umbenennen ist nach dem ersten Commit sicher (git branch -M main) – bei einem ungeborenen Branch gibt es noch nichts umzubenennen, weshalb die falsche Reihenfolge der Befehle einen Zyklus verschwendet.
Effektive Remote-URL. Es lohnt sich, sie genau zu kennen, weil es einfach ist, sie falsch zu überprüfen: git remote get-url expandiert bereits url.<base>.insteadOf, ebenso wie git ls-remote --get-url. Der Vergleich dieser beiden erkennt daher nichts. Der rohe Wert überlebt nur in git config --get remote.<name>.url, also vergleicht das Skript diesen mit git remote get-url --push (die --push-Form deckt zusätzlich pushurl und pushInsteadOf ab, was ein Push tatsächlich verwendet). Wenn die beiden unterschiedlich sind, ist die konfigurierte URL des Benutzers nicht diejenige, die Git kontaktieren wird. Die klassische Falle ist ein globales url."https://github.com/".insteadOf = [email protected]:, das SSH stillschweigend auf HTTPS umleitet und damit zu dem Konto, das der Credential Helper hält – oft nicht dem vom Benutzer beabsichtigten. Melden Sie immer die effektive URL und kennzeichnen Sie die Abweichung explizit.
Authentifizierendes Konto. Für SSH löst das Skript den Host über ssh -G auf (sodass Host-Aliase wie github-personal zu ihrem tatsächlichen Hostnamen und Schlüssel verfolgt werden) und fragt dann GitHub direkt mit ssh -T. GitHub antwortet Hi <benutzername>! und beendet sich mit Exit-Code 1 – Exit 1 ist hier der Erfolgsfall, kein Fehler. Für HTTPS liest es das aktive gh-Konto aus. Vergleichen Sie dieses Konto mit dem Besitzer-Segment der URL: Ein Missmatch bedeutet, dass der Push einen 403-Fehler erzeugt oder im falschen Namespace landet.
Commit-Identität. Das aus der globalen Konfiguration geerbte user.email ist der stille Fehler. Der Push authentifiziert sich als ein Konto, während jeder Commit unter einer anderen Adresse autorisiert wird – und die Behebung später erfordert Amendieren oder Umschreiben der Geschichte. Behandeln Sie eine global definierte Identität in einem Repo, dessen Remote einem anderen Besitzer gehört, als WARN, das prominent gemeldet werden sollte, auch wenn technisch noch nichts kaputt ist.
Remote-Zustand. Leeres Remote bedeutet, der erste Push ist sauber. Vorhandene Refs bedeuten, dass ein einfacher Push als Nicht-Fast-Forward abgelehnt wird und der Benutzer zuerst pullen/rebasen muss – sagen Sie das, bevor sie auf die Ablehnung stoßen. Ein Fehler hier bedeutet normalerweise, dass das Repo nicht existiert oder das Konto keinen Zugriff hat; GitHub meldet beides absichtlich als „nicht gefunden“, bieten Sie daher beide Erklärungen an, anstatt zu raten.
Dry-Run-Push. Nur möglich, sobald ein Commit existiert. Dies ist der echte End-to-End-Check – er testet Auth und Ref-Aushandlung, ohne zu schreiben. Beachten Sie seinen blinden Fleck: Er wird serverseitige Ablehnungen wie GH007 (E-Mail-Privatsphäre) nicht abfangen, da diese erst beim tatsächlichen Empfang ausgewertet werden.
Berichterstattung
Geben Sie eine kurze Tabelle der Prüfungen und dann – nur für die Dinge, die fehlgeschlagen sind oder gewarnt haben – die genauen Befehle zu deren Behebung in ausführbarer Reihenfolge aus. Geben Sie bestandene Prüfungen nicht als Prosa aus; der Benutzer möchte wissen, was falsch ist und was er eingeben soll.
Wenn die Identität gesetzt werden muss, bevorzugen Sie Repo-lokale Konfiguration gegenüber der Änderung der globalen, da der ganze Punkt darin besteht, dass sich dieses Repo von der Standardeinstellung des Rechners unterscheidet:
git config user.name "<konto>"
git config user.email "<email>"
Wenn mehrere Repos die gleiche Behandlung benötigen, erwähnen Sie includeIf als dauerhaften Fix:
[includeIf "gitdir:~/persönlich/"]
path = ~/.gitconfig-persönlich
Und wenn der Push mit GH007 abgelehnt wird, verweisen Sie auf die @users.noreply.github.com-Adresse aus GitHub → Einstellungen → E-Mails, anstatt auf eine persönliche Adresse zu raten – Schlüsselkommentare und lokale Konfiguration sind Etiketten, kein Beweis dafür, was das Konto akzeptiert.