Seite 9 - Git

Git Hooks sind Skripte, die Git automatisch bei bestimmten Ereignissen wie Commit, Push oder Merge ausführt, lokal im Verzeichnis .git/hooks und serverseitig im blanken Repository. Dieser Artikel zeigt, wie sich Client und Server Hooks unterscheiden, wie ein pre-commit Hook Schritt für Schritt entsteht, wie Git Exit Codes interpretiert und wie core.hooksPath Hooks endlich teamweit versionierbar macht.

Ein vollständiger git clone überträgt jede Version jeder Datei aus der gesamten Historie, auch wenn nur der aktuelle Stand benötigt wird. Partial Clone und Shallow Clone reduzieren die übertragene Datenmenge auf unterschiedliche Weise und eignen sich für unterschiedliche Einsatzszenarien, von CI Runnern bis zu Entwicklerarbeitsplätzen.

Eine sauber konfigurierte .gitattributes-Datei löst Probleme, die viele PHP-Teams für unvermeidbar halten: CRLF-Rauschen zwischen Windows und Linux, aufgeblähte Deployment-Archive, verzerrte GitHub-Sprachstatistik durch Vendor-Code und unlesbare Pull-Request-Diffs bei generierten oder minifizierten Dateien. Dieser Artikel zeigt jede relevante Direktive an echten Beispielen für PHP- und Magento-Projekte, inklusive Zeilenenden, export-ignore, linguist-Attributen und Diff-Treibern für den produktiven Entwickleralltag.

Seit Git 2.34 lässt sich ein bereits vorhandener SSH-Schlüssel direkt zum Signieren von Commits nutzen, ganz ohne separate GPG-Installation und ohne eigene Schlüsselverwaltung. Wer SSH ohnehin schon für Push und Pull einsetzt, kommt so mit deutlich weniger Aufwand zu verifizierten Commits.

Eine verworrene Git-History mit hunderten WIP-Commits macht Bisect nutzlos, Reviews mühsam und Blame unzuverlässig. Klare Konventionen wie atomare Commits, Rebase vor dem Merge und disziplinierte Commit-Messages verwandeln das Log in ein verlässliches Werkzeug für Debugging und Nachvollziehbarkeit, ohne die Geschwindigkeit im Team zu bremsen.

Git Submodules versprechen, mehrere Repositories sauber zu verzahnen, doch in der Praxis sorgen vergessene Updates, ein verwirrender Detached HEAD Zustand und divergierende Commit Pins im Team regelmäßig für Frust. Dieser Artikel erklärt, wie Submodules technisch funktionieren, vergleicht sie mit git subtree, Composer basierten Abhängigkeiten und Monorepos, und zeigt, welches Werkzeug für typische Magento Multi Repo Setups tatsächlich passt.

Monorepo oder Polyrepo ist eine der folgenreichsten Architekturentscheidungen für Git-Projekte, weil sie Commit-Verhalten, Zugriffsrechte, CI/CD-Pipelines und die tägliche Entwicklerroutine über Jahre hinweg prägt. Dieser Artikel vergleicht beide Strategien anhand konkreter Kriterien wie Teamgröße, Kopplung und Tooling und zeigt, wie Magento-Agenturen Kundenprojekte und Custom-Module sinnvoll zwischen app/code und eigenen Composer-Paketen aufteilen.

Eine umbenannte Datei wirkt für git log wie eine neue Datei. Mit --follow bleibt die vollständige Historie sichtbar, allerdings nur unter bestimmten Bedingungen.

Ein pre-commit Hook läuft, bevor Git den Commit tatsächlich erstellt, und kann ihn bei Regelverstößen vollständig verhindern. Dieser Artikel zeigt, welche Prüfungen wie Linting, Formatierung und schnelle Unit-Tests dort sinnvoll sind, warum Geschwindigkeit entscheidend ist, und wie sich Hand-geschriebene Skripte gegenüber dem pre-commit Framework schlagen.

Eine schlecht gepflegte .gitignore führt dazu, dass generierte Dateien, Zugangsdaten und IDE-Konfigurationen versehentlich im Repository landen oder dass Teammitglieder ständig lokale Änderungen wegwerfen. Dieser Artikel erklärt globale und projektspezifische Regeln, die genaue Pattern-Syntax, das Risiko bereits getrackter Dateien und eine praxistaugliche Baseline für PHP- und Magento-Projekte.