Seite 3 - 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.

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.

Wer Merge und Rebase austauschbar nutzt, riskiert verlorene Commits, verwirrende Historie und Force-Push-Chaos im Team. Beide Befehle integrieren divergierende Branches, aber auf grundlegend unterschiedliche Weise. Dieser Artikel erklaert die interne Mechanik beider Operationen und liefert einen klaren, praxistauglichen Entscheidungsrahmen für den taeglichen Einsatz.

Git Flow und GitHub Flow lösen dasselbe Problem auf unterschiedliche Weise: wie ein Team parallel an Features arbeitet, ohne sich gegenseitig zu blockieren. Dieser Artikel erklärt beide Branching-Strategien im Detail, zeigt echte Git-Befehle für den Alltag und liefert eine klare Empfehlung, welches Modell für kleine und welches für große Teams besser passt.

Wer Commit-Messages ohne Validierung durchwinkt, sammelt über Monate eine Historie aus Nachrichten wie fix und wip, die sich weder für Changelogs noch für automatisierte Releases nutzen lässt. Der commit-msg-Hook prüft jede Nachricht, bevor der Commit entsteht, und erzwingt mit commitlint und Husky ein konsistentes Format, das Tools wie semantic-release zuverlässig auswerten können.

Wer mitten in einer Aufgabe dringend den Branch wechseln muss, kennt das Dilemma zwischen halbfertigem Code und einem sauberen Arbeitsverzeichnis. git stash legt uncommittete Änderungen sicher beiseite, verwaltet mehrere benannte Stashes parallel, erlaubt partielles Sichern einzelner Hunks und unterscheidet klar zwischen pop und apply, damit unterbrochene Arbeit nie verloren geht.

Branches, Commits, Diffs und Merges wirken wie unabhängige Konzepte, sind aber technisch nur Zeiger in denselben Objektgraphen. Dieser Artikel steigt bewusst unter add, commit und branch und zeigt mit git cat-file und git hash-object direkt am Objektspeicher, wie Blobs, Trees und Commits aufgebaut sind, wie sie sich gegenseitig referenzieren, und warum Git seine Objekte per SHA-1 oder SHA-256 statt über Dateinamen adressiert.

Wer Git ohne durchdachte Konfiguration nutzt, committet mit falscher Identität, kämpft mit unübersichtlicher Historie und verliert Zeit beim Wechsel zwischen Projekten. Die drei Config-Ebenen system, global und local folgen einer klaren Präzedenz, mit der sich Editor, Rebase-Verhalten, Aliases und projektspezifische Overrides über includeIf sauber und nachvollziehbar einrichten lassen.