Seite 2 - Git

Wer Commit-Messages nach Lust und Laune formuliert, verliert die Möglichkeit, Änderungen maschinell auszuwerten und Releases automatisch zu planen. Conventional Commits standardisiert das Format auf type(scope): description und macht die Commit-Historie damit zur verlässlichen Grundlage für automatisierte Changelogs, semantische Versionsnummern und vollautomatische Releases, ganz ohne manuelle Zwischenschritte in der CI/CD-Pipeline.

Squash-Merge verspricht eine makellose main-History mit einem Commit pro Pull Request, doch dieser Komfort hat einen Preis. Wer granulare Commits vorschnell zusammenfasst, verliert Bisect-Präzision, Autorenschaft und den dokumentierten Entstehungsweg großer Refactorings. Dieser Artikel zeigt, wie Squashen technisch funktioniert, wann es Teams wirklich hilft und wann Rebase-Merge oder Merge-Commits die bessere Wahl bleiben.

Ein Git-Workflow, der nur in einem Wiki dokumentiert ist, veraendert kein Entwicklerverhalten. Erst wenn Branch-Namen, Commit-Formate und Review-Regeln durch Hooks, CI-Checks und ein durchdachtes Onboarding automatisch greifen, wird aus einer guten Absicht eine gelebte Konvention, die auch bei wachsendem Team und wechselnden Kollegen stabil bleibt.

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.

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