Seite 7 - Git

Lokale Git-Hooks landen in .git/hooks und werden nie mit dem Repository versioniert, wodurch jeder Entwickler sie einzeln einrichten muss und Teams faktisch keine verlässliche Durchsetzung von Codequalität vor dem Commit haben. Husky verteilt Hooks automatisch über npm, lint-staged beschränkt Prüfungen auf geänderte Dateien und commitlint erzwingt saubere Commit-Nachrichten, ganz ohne manuelle Einrichtung.

Nicht jedes Git-Projekt läuft über ein zentrales Forge mit Pull-Request-Oberfläche. git format-patch erzeugt aus einer Reihe von Commits versendbare Patch-Dateien, die Empfänger mit git am wieder zu vollständigen Commits zusammensetzen können, ganz ohne GitHub, GitLab oder ein anderes Web-Interface dazwischen. Dieser Artikel zeigt, wie sich Patch-Serien erzeugen, mit einem Cover Letter versehen, versionieren und über git send-email verschicken lassen, und wann sich dieser Workflow gegenüber Pull Requests tatsächlich lohnt.

Wer Branches und Deployment-Umgebungen nicht sauber trennt, deployt irgendwann versehentlich ungetesteten Code auf die Produktion. Dieser Artikel zeigt, wie Magento-Teams Branches eindeutig auf dev, staging und prod abbilden, Code per Merge und Tag statt per Rebase durch die Umgebungen befördern, Konfiguration sauber aus der Historie heraushalten und Branches sowie Pipelines pro Umgebung gezielt absichern.

Ein schwerfälliger Pull-Request-Workflow bremst ganze Teams aus, riesige Diffs, fehlender Kontext und manuelle Merge-Koordination summieren sich zu Reibungsverlusten. Dieser Artikel zeigt, wie kleine Pull Requests, Draft PRs, PR-Templates sowie Required Checks und Auto-Merge zusammenspielen, um Reviews schneller und den gesamten Workflow planbarer zu machen.

Ohne Reviewer, ohne parallel arbeitendes Team stellt sich für Solo-Entwickler eine andere Frage als in Unternehmensteams: nicht wie sich Konflikte zwischen mehreren Personen vermeiden lassen, sondern welcher Teil des üblichen Git-Prozesses tatsächlich noch einen Nutzen hat und welcher nur unnötigen Aufwand erzeugt.

Ein main-Branch ohne Schutz ist nur einen falschen Force-Push von einem Totalschaden entfernt. Dieser Artikel zeigt, was Protected Branches auf GitHub und GitLab wirklich verhindern, wie Required Status Checks und Approval-Regeln funktionieren, welche Rolle CODEOWNERS spielt und mit welcher Baseline Magento- und Hyvä-Agenturen ihren main-Branch praxistauglich absichern, ohne das Team auszubremsen.

git archive erzeugt aus einem beliebigen Commit, Tag oder Tree einen reinen Datei-Snapshot als zip- oder tar-Archiv, komplett ohne Commit-Historie und ohne .git-Verzeichnis. Wer Release-Pakete bisher per Hand aus einem Checkout zusammenkopiert, findet hier ein deterministisches, direkt in CI-Pipelines einsetzbares Werkzeug, das Git bereits mitbringt.

Trunk-Based Development ersetzt lange Feature-Branches durch kurzlebige Zweige, die mehrmals täglich in den Main-Branch zurückfließen. Feature Flags machen es möglich, unfertigen Code sicher auszuliefern, ohne die Anwendung zu gefährden, während eine schnelle, zuverlässige CI-Pipeline jeden Commit sofort auf Regressionen prüft und den Main-Branch dauerhaft auslieferbar hält.

Ein Review, das den eigenen Feature-Branch kurz verdrängt, kostet mehr als nur die Zeit für git stash und git checkout: Laufende Dev-Server, Compiler-Watcher oder Docker-Container geraten dabei oft ebenfalls aus dem Takt. git worktree legt stattdessen einen zusätzlichen, unabhängigen Checkout desselben Repositorys in einem eigenen Verzeichnis an, sodass der zu prüfende Branch parallel zum eigenen Arbeitsstand geöffnet bleibt. Dieser Artikel zeigt, wie sich Worktrees gezielt für Reviews einsetzen, verwalten und wieder aufräumen lassen.

Uneinheitliche Branch-Namen wirken im Alltag harmlos, bis eine Deployment-Pipeline die falsche Umgebung trifft oder ein automatisiertes Cleanup-Skript einen aktiven Branch löscht. Klare Präfixe wie feature, bugfix und hotfix, kombiniert mit Ticket-IDs aus Jira oder GitHub Issues, schaffen Nachvollziehbarkeit, ermöglichen zuverlässige CI-Automatisierung und lassen sich mit einem einfachen Naming-Check-Hook im gesamten Team durchsetzen.