Seite 4 - Git

Wer Releases direkt von main oder develop ausliefert, riskiert instabile Versionen und blockierte Feature-Entwicklung. Strukturierte Release-Branches trennen Stabilisierung von neuer Entwicklung, semantische Versionierung macht Änderungen nachvollziehbar, signierte Tags schaffen vertrauenswuerdige Auslieferungspunkte, Cherry-Pick-Backporting bringt Bugfixes sicher in aeltere unterstuetzte Versionen und CI/CD-Pipelines reagieren automatisch und kontrolliert auf Branches und Tags.

In Magento-Projekten mit mehreren parallel arbeitenden Entwicklern und regelmäßigen Modul-Updates gehört ein Merge-Konflikt in composer.lock zu den häufigsten und gleichzeitig am häufigsten falsch gelösten Git-Problemen. Die Datei ist maschinengeneriert, mehrere tausend Zeilen lang und enthält einen Hash, der zur eigentlichen composer.json passen muss, weshalb ein manuelles Zusammenführen der Konfliktmarker fast immer zu einer inkonsistenten, aber scheinbar gültigen Datei führt. Dieser Artikel zeigt den korrekten Lösungsweg und wie sich solche Konflikte im Team von vornherein reduzieren lassen.

git blame wird in vielen Teams als Werkzeug zur Schuldzuweisung missverstanden, dabei liefert es wertvollen Kontext: wer eine Zeile wann und in welchem Zusammenhang geändert hat. Dieser Artikel zeigt praxisnah, wie ihr mit Flags wie -w, -C und -M präzisere Ergebnisse erhaltet, Massen-Reformatierungen sauber ausblendet und blame-Ausgaben in PhpStorm und der Kommandozeile richtig interpretiert.

Wer Magento-Deployments über FTP-Uploads oder manuelle Dateikopien vom eigenen Rechner erledigt, verliert jede Nachvollziehbarkeit darüber, welcher Code tatsächlich live ist. Dieser Artikel zeigt, wie annotierte Git-Tags als unveränderliche Produktionswahrheit dienen, wie CI/CD-Pipelines automatisiert auf Branches und Tag-Pushes reagieren, wie ein klares Branch-zu-Umgebung-Mapping Staging, Review-Umgebungen und Produktion sauber trennt, und warum ein Rollback im Ernstfall nur ein erneutes Deployment des vorherigen Tags bedeutet.

Wer vendor Verzeichnisse committet oder composer.lock ignoriert, riskiert inkonsistente Installationen zwischen Entwicklerrechner, CI Pipeline und Produktivserver. Dieser Artikel zeigt, warum composer.lock statt vendor versioniert werden sollte, wie private Magento Marketplace Pakete sicher über auth.json eingebunden werden, und wie sich composer.lock Merge Konflikte zwischen Branches sauber auflösen lassen, damit Deployments jederzeit reproduzierbar bleiben.

In Monorepos mit tausenden Verzeichnissen wird ein vollständiger Checkout schnell zur Belastung für Festplatte, Ladezeit und IDE Indizierung. Git Sparse Checkout erlaubt es, gezielt nur die Verzeichnisse ins Working Directory zu materialisieren, mit denen tatsächlich gearbeitet wird, während die vollständige Historie im Repository erhalten bleibt.

Wer dieselben Bash-Funktionen für Logging, Retry-Logik und Benachrichtigungen in jedem Repository neu schreibt, produziert Wartungsaufwand, den eine einzige, geteilte Library-Datei vermeidet. Richtig gebaut, versioniert und getestet wird eine solche Bash-Bibliothek zum stabilen Fundament für alle CI-Pipelines eines Teams, statt zur nächsten Quelle für Copy-Paste-Bugs.

Wer einen lang laufenden Feature-Branch regelmäßig gegen main rebased, kennt das Problem: Derselbe Konflikt in derselben Datei taucht bei jedem Rebase erneut auf. git rerere merkt sich die einmal gefundene Lösung und wendet sie beim nächsten identischen Konflikt automatisch wieder an, ganz ohne externes Werkzeug.

Eine langsame CI-Pipeline liegt selten nur an der YAML-Datei. Wie ein Team branched, committet und Pull Requests strukturiert, entscheidet maßgeblich darüber, wie effizient GitHub Actions arbeiten kann.

Wer Git täglich über die Kommandozeile bedient, tippt bestimmte Befehlskombinationen dutzende Male am Tag, oft mit denselben Optionen und Formatierungsparametern. Git-Aliase kapseln solche wiederkehrenden Befehle in einem einzigen, kurzen Kommando und sparen dabei nicht nur Tastenanschläge, sondern auch Denkarbeit, weil komplexe Standardworkflows nicht jedes Mal neu zusammengesetzt werden müssen. Dieser Artikel zeigt, wie einfache und fortgeschrittene Aliase funktionieren, welche sich in der Praxis bewährt haben und wie sie sich teamweit verteilen lassen.