Seite 3 - Git

Wer ständig zwischen Feature-Branch, Hotfix und Pull-Request-Review hin- und herspringt, verliert Zeit mit Stashen, Wechseln und dem Warten auf neu installierte Abhängigkeiten. Git Worktree löst das strukturell: mehrere Branches gleichzeitig in eigenen Verzeichnissen, ein gemeinsames Repository, kein Kontextverlust und keine unterbrochene Arbeit mehr.

Merge-Konflikte gehören zum Alltag jedes Git-Teams und schrecken viele Entwickler unnötig ab. Dieser Artikel erklärt, wie Konfliktmarker zu lesen sind, wann sich ein grafisches Mergetool wie VS Code, Meld oder PhpStorm lohnt, wie git rerere wiederkehrende Konflikte automatisch löst und mit welchen Strategien Teams die Zahl der Konflikte in Feature Branches von Anfang an reduzieren.

Ein einzelner großflächiger Formatierungs-Commit reicht aus, um git blame für eine ganze Datei nutzlos zu machen, weil jede Zeile plötzlich auf diesen einen Commit zeigt statt auf die eigentliche fachliche Änderung. Die Datei .git-blame-ignore-revs löst genau dieses Problem, ohne die Commit-Historie selbst anzufassen.

Client-seitige Git Hooks sind bequem, aber jeder Entwickler kann sie mit --no-verify umgehen, löschen oder einfach nie installieren. Server-Side Hooks laufen dagegen auf dem zentralen Git-Server, wo niemand direkten Zugriff hat, und werden damit zum einzigen echten Durchsetzungspunkt für Force-Push-Schutz, Dateigrößen-Limits und Branch-Namenskonventionen im Team.

Die CODEOWNERS Datei weist Pull und Merge Requests automatisch den richtigen Reviewern zu, basierend auf den geänderten Dateipfaden. Dieser Artikel erklärt Syntax und Path Matching Regeln, zeigt wie man CODEOWNERS mit Branch Protection auf GitHub und GitLab kombiniert, liefert Praxisbeispiele für Magento 2 und Hyvä Projekte und beschreibt, wie das Team die Datei dauerhaft aktuell hält.

Ein guter Changelog Generator liest die Commit-History aus, erkennt Typ und Umfang jeder Änderung und baut daraus ein strukturiertes CHANGELOG.md, ganz ohne manuelles Nachtragen. Dieser Artikel zeigt, wie ein solcher Changelog Generator als reines Bash-Skript entsteht, welche Fallstricke beim Parsen von Conventional Commits lauern und wie sich das Ergebnis sauber in eine Release-Pipeline einhängen lässt.

Ein versehentlich committetes Datenbank-Passwort oder eine mehrere Gigabyte große node_modules-Historie lässt sich nicht mit einem neuen Commit reparieren, denn alte Versionen bleiben für immer im Repository erhalten. Dieser Artikel zeigt, wann eine History-Bereinigung wirklich notwendig ist, wie der BFG Repo-Cleaner Secrets und große Dateien schnell entfernt, und welche Koordination ein Force-Push im Team erfordert.

Lange lebende Feature-Branches wachsen unbemerkt zu unübersichtlichen Merge-Konflikten heran und kosten Entwicklerteams wertvolle Zeit bei jedem Release. Dieser Artikel zeigt praxisnah, wie ihr Feature-Branches kurz und fokussiert haltet, regelmäßig mit main synchronisiert, überladene Branches frühzeitig erkennt und sauber aufteilt, und mit einem klaren Branch-per-Ticket-Workflow Merge-Hölle in Magento- und PHP-Projekten dauerhaft vermeidet.

Wenn irgendwo zwischen hunderten Commits ein Bug eingeschlichen ist, kostet manuelles Durchklicken der Historie wertvolle Zeit. git bisect findet den schuldigen Commit per Binärsuche in wenigen Schritten, egal ob manuell getestet oder vollautomatisch per Testskript, und macht aus stundenlanger Fehlersuche eine Sache von Minuten.

Ein generisches Code-Review übersieht die Fallen, die speziell in Magento zu Produktionsproblemen führen: falsch eingesetzte Preferences, gebrochene public APIs, InstallScripts statt Schema. Eine Magento-spezifische Code-Review-Checkliste macht diese Risiken systematisch sichtbar, bevor sie gemergt werden.