Der Editor hängt an der Produktion

Ausgangslage

~/projects auf dem VPS ist per Remote-SSH direkt im Editor offen — und dieses Verzeichnis ist zugleich die Produktivumgebung. Eine Änderung dort wirkt sofort, der Commit dokumentiert sie nur nachträglich. Parallel existiert eine zweite Arbeitskopie auf dem MacBook Air, in der dieselben Dateien wirkungslos sind.

Entscheidung

Ich behandle beide Kopien nicht als gleichwertig. Nur eine davon ist live, und das muss beim Arbeiten jederzeit klar sein — nicht durch Disziplin allein, sondern durch Git als Nachweis, welcher Zweig gerade welchen Stand trägt.

Umsetzung

Der Befund vom Dezember 2025 zeigt, warum das nötig ist: Konfigurationsdateien wurden nach infra/nginx/conf.d verschoben statt kopiert, der produktive Mount zeigte weiter auf den alten Pfad. Sieben Monate lang fiel das niemandem auf — bis ein nginx-Neustart beide Domains offline nahm. Die .gitignore schliesst heute gezielt aus, was nicht ins Repository gehört: .env, Schlüssel, aber auch data/ (496 MB Laufzeitdaten) und *.sql (Dumps mit Passwort-Hashes aus mysql.user). Vor dem ersten Push prüft git ls-files auf Geheimnisse, danach git ls-tree -r origin/main den tatsächlichen Remote-Stand.

Erkenntnis

Git hätte die Divergenz von Dezember 2025 sichtbar gemacht — war aber nur auf einem der beiden Zweige aktiv. Mit der CI/CD-Pipeline entfällt die Disziplin, vor jeder Änderung git pull nicht zu vergessen: Von git push zu live beschreibt, wie.