Seite 6 - Git

Wer mitten in einer Aufgabe dringend den Branch wechseln muss, kennt das Dilemma zwischen halbfertigem Code und einem sauberen Arbeitsverzeichnis. git stash legt uncommittete Änderungen sicher beiseite, verwaltet mehrere benannte Stashes parallel, erlaubt partielles Sichern einzelner Hunks und unterscheidet klar zwischen pop und apply, damit unterbrochene Arbeit nie verloren geht.

Ein Commit-Template gibt vor, wie eine Commit-Nachricht aufgebaut sein soll, doch ohne technische Durchsetzung bleibt es eine Empfehlung, die im Alltag schnell ignoriert wird. Dieser Artikel zeigt, wie aus einer einfachen .gitmessage Datei ein Regelwerk wird, das lokal, im Hook und in der CI tatsächlich greift.

Git verwendet standardmäßig den Myers-Algorithmus, um Unterschiede zwischen zwei Dateiversionen zu berechnen, doch das ist längst nicht die einzige Option. Patience Diff und Histogram Diff verfolgen einen anderen Ansatz und liefern bei verschobenem oder umsortiertem Code oft deutlich verständlichere Ergebnisse. Dieser Artikel erklärt, wie die vier in Git verfügbaren Algorithmen intern arbeiten, woran sich ihre Unterschiede in der Praxis zeigen und wie sich der passende Algorithmus dauerhaft konfigurieren lässt.

Release Notes richten sich an Nutzer und Stakeholder, nicht an Entwickler, und brauchen deshalb einen anderen Ton als ein technischer Changelog. Dieser Artikel zeigt, wie ein Bash-Skript aus dem Commit-Bereich zwischen zwei Tags automatisch lesbare Release Notes mit Mitwirkenden, hervorgehobenen Highlights und Vergleichslink erzeugt und direkt an die GitHub oder GitLab Release API übergibt.

Branches, Commits, Diffs und Merges wirken wie unabhängige Konzepte, sind aber technisch nur Zeiger in denselben Objektgraphen. Dieser Artikel steigt bewusst unter add, commit und branch und zeigt mit git cat-file und git hash-object direkt am Objektspeicher, wie Blobs, Trees und Commits aufgebaut sind, wie sie sich gegenseitig referenzieren, und warum Git seine Objekte per SHA-1 oder SHA-256 statt über Dateinamen adressiert.

Wer Git ohne durchdachte Konfiguration nutzt, committet mit falscher Identität, kämpft mit unübersichtlicher Historie und verliert Zeit beim Wechsel zwischen Projekten. Die drei Config-Ebenen system, global und local folgen einer klaren Präzedenz, mit der sich Editor, Rebase-Verhalten, Aliases und projektspezifische Overrides über includeIf sauber und nachvollziehbar einrichten lassen.

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.

Ein Mirror-Repository bildet ein Git-Repository nicht nur inhaltlich, sondern strukturell vollständig ab, inklusive aller Branches, Tags und internen Referenzen. Das eignet sich für Backups, Ausfallsicherheit und Migrationen zwischen Hosting-Plattformen, erfordert aber ein klares Verständnis davon, wie git push --mirror ein Ziel-Repository tatsächlich überschreibt.

Nicht jede Umgebung hat direkten Netzwerkzugriff auf einen Git Server, sei es aus Sicherheitsgründen in abgeschotteten Netzen oder schlicht mangels Internetverbindung. Git Bundle packt Commits, Bäume und Blobs in eine einzelne Datei, die sich per USB Stick, E Mail oder jedem anderen Uebertragungsweg weitergeben und wie ein reguläres Remote einbinden lässt.