Git

Ein vergessener API-Key in einem Commit reicht aus, um Zugangsdaten dauerhaft offenzulegen, selbst wenn die Datei später wieder gelöscht wird. Dieser Artikel zeigt, wie gitleaks und git-secrets Secrets schon vor dem Commit erkennen, warum eine zusätzliche CI-Prüfung nötig ist, und welche Reihenfolge bei einem tatsächlichen Leak über den Schaden entscheidet.

Wer Git nur als Blackbox mit mysteriösen Befehlen begreift, tippt Kommandos nach Gefühl und wundert sich über Fehlermeldungen. Dieser Artikel erklärt das Drei-Bereiche-Modell aus Working Directory, Staging Area und Repository, zeigt was git add, commit, checkout und restore technisch wirklich tun, und liefert damit das Mentalmodell, mit dem spätere Git-Konzepte wie Branches, Merges und Reset endlich logisch werden.

Eine gute Commit-Message erklärt, warum eine Änderung nötig war, nicht nur was sich im Code verändert hat, denn das zeigt der Diff ohnehin. Mit der 50/72-Regel, dem Imperativ in der Betreffzeile, sauberen Trailern für Ticket-Referenzen und optional Conventional Commits wird aus der Git-Historie ein durchsuchbares Archiv, das Debugging und Code-Archäologie Monate später erheblich beschleunigt.

Ein unbedachter git reset --hard oder ein missglückter Rebase fühlt sich nach einem endgültigen Verlust an, ist es aber selten. Das Reflog protokolliert lokal jede Bewegung von HEAD und macht verschwundene Commits meist innerhalb weniger Minuten wieder auffindbar. Dieser Artikel zeigt, wie das Reflog funktioniert, wie lange Einträge erhalten bleiben und wie eine saubere Recovery in der Praxis abläuft.

Wer PSD-Dateien, Videos oder Archive direkt in Git committet, bläht die Repository-Grösse und die Clone-Zeit für das ganze Team unnötig auf, weil Gits Delta-Kompression bei Binärdaten kaum greift. Git LFS ersetzt diese Dateien durch schlanke Pointer und lagert die eigentlichen Inhalte extern, ohne dass sich am gewohnten Commit- und Push-Workflow etwas ändert.

Ein einmal committetes Secret bleibt in der Git-Historie erreichbar, auch nach dem Löschen der Datei. Dieser Artikel zeigt, warum das so ist, wie Pre-Commit-Hooks und CI-Scanner Leaks von vornherein verhindern, und welche Reihenfolge bei einem echten Vorfall zählt: zuerst die Zugangsdaten rotieren, dann die Historie bereinigen.

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.

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.