Seite 2 - Git

Ohne einen strukturierten Versionierungsprozess enden interne TypeScript-Pakete entweder bei einer einzigen globalen Versionsnummer für das gesamte Monorepo oder bei handgeschriebenen Changelogs, die niemand konsistent pflegt. Changesets löst beide Probleme mit einem deklarativen, review-fähigen Workflow.

Wer einen Commit, Tag oder eine Remote-Referenz direkt auscheckt, landet im Detached-HEAD-Zustand und riskiert, dort erstellte Commits durch den nächsten Branch-Wechsel unsichtbar werden zu lassen. Dieser Artikel erklärt, wie HEAD in Git wirklich funktioniert, warum Commits verloren wirken können, obwohl sie es selten sind, und wie ihr mit git branch, git switch und git reflog jede Situation sicher rettet.

Ein gutes Code-Review prüft weit mehr als Einrückung und Namenskonventionen. Es deckt logische Fehler, fehlende Testfälle, Sicherheitslücken und Kompatibilitätsprobleme auf, bevor sie in Produktion landen. Dieser Artikel zeigt, wie erfahrene Reviewer Pull Requests systematisch durchgehen, konkretes statt vages Feedback geben und mit Git-Tools den Kontext einer Änderung verstehen, bevor sie kommentieren.

Wer zwischen Feature-Branches wechselt, ohne die passende Datenbank mitzunehmen, testet gegen falsche Zustände oder verliert Fixtures. Ein automatisierter Workflow mit Datenbank-Snapshots pro Branch macht den Wechsel so unkompliziert wie ein normales git checkout.

Git gilt gemeinhin als robust, weil jedes Objekt über seinen Inhalts-Hash identifiziert wird, doch auch eine Objektdatenbank aus SHA-Hashes ist nicht immun gegen defekte Festplatten, abgebrochene Prozesse oder versehentlich gelöschte Dateien. Das eingebaute Kommando git fsck durchsucht genau diese Objektdatenbank nach Inkonsistenzen und macht Probleme sichtbar, bevor sie zu echtem, irreversiblem Datenverlust führen. Dieser Artikel erklärt, was fsck tatsächlich prüft, wie die häufigsten Fehlermeldungen zu lesen sind und mit welchen Schritten sich ein beschädigtes Repository reparieren lässt.

Ein einziger versehentlicher Commit mit Datenbank-Zugangsdaten oder dem Crypt Key aus app/etc/env.php kann ein komplettes Magento-Projekt kompromittieren, selbst wenn das Repository später wieder privat gesetzt wird. Dieser Artikel zeigt, welche Dateien niemals in Git landen dürfen, wie eine saubere gitignore Baseline aussieht und wie Secrets Manager sowie Pre Commit Scanning das zuverlässig verhindern.

Wer einen Feature-Branch mit chaotischer Commit-Historie zur Review einreicht, kostet dem Team Zeit und verschenkt Vertrauen. Dieser Guide zeigt Schritt für Schritt, wie ihr mit git rebase -i Commits umordnet, zusammenfasst, umbenennt oder entfernt, Konflikte sicher löst und einen missglückten Rebase jederzeit über die reflog wieder rückgängig macht.

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.