Seite 4 - Git

Wer für einen einzelnen Hotfix gleich einen kompletten Feature-Branch mergt, holt ungewollte Commits, Konflikte und Rauschen in die Historie. Git Cherry-Pick überträgt genau einen Commit auf einen anderen Branch, mit eigener SHA und nachvollziehbarer Herkunft über die Flag -x. Dieser Artikel zeigt, wie ihr Cherry-Pick gezielt für Hotfixes einsetzt, Konflikte löst und divergente Historie vermeidet.

Monster-Commits mit gemischten Refactorings, Bugfixes und neuen Features machen Code-Reviews langsam, git bisect nutzlos und einzelne Änderungen unmöglich rückgängig zu machen. Mit git add -p, git commit -p und git rebase -i lässt sich jede Änderung in klar abgegrenzte, atomare Commits aufteilen, die einzeln nachvollziehbar, testbar und im Zweifel gezielt revertierbar bleiben.

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.

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.

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.

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.

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.

Ein gewachsenes .git-Verzeichnis, das mehrere Gigabyte umfasst, ist selten ein Zufall, sondern die Summe jedes Commits, jedes Rebase und jeder versehentlich eingecheckten Binärdatei, die Git niemals von selbst löscht. Dieser Artikel erklärt, wie lose Objekte zu delta-komprimierten Packfiles werden, was git gc technisch wirklich tut, welche Rolle der Reflog beim Schutz vor Datenverlust spielt, und wie man ein aufgeblähtes Repository gezielt diagnostiziert und wieder verschlankt.

Wer git log nur mit der Standardausgabe nutzt, verschenkt eines der mächtigsten Diagnosewerkzeuge im täglichen Entwicklungsalltag. Mit gezielten Filtern nach Autor, Zeitraum und Inhalt, mit eigenen Pretty Formaten für Skripte und mit der Pickaxe Suche lässt sich jede Codezeile bis zu ihrem Ursprung zurückverfolgen, ohne die Historie manuell zu durchsuchen.