Einführung

In Git ist ein Branch nur eine bewegliche Referenz auf einen Commit. Einen Branch zu erstellen bedeutet, eine 41-Byte-Datei zu erstellen. Verglichen mit zentralisierten Systemen, in denen Branches vollständige Verzeichniskopien sind, macht Gits Modell Branching günstig genug, um es leichtfertig zu nutzen.

Was ein Branch tatsächlich ist

cat .git/refs/heads/main
# a1b2c3d4e5f6...
git rev-parse main

Dieser Hash ist die Spitze des Branches. Der "Branch" selbst ist die Kette von Commits, die von der Spitze über Eltern-Zeiger erreichbar sind.

Branches erstellen

git branch feature/login           # erstellen, nicht wechseln
git switch -c feature/login        # erstellen und wechseln
git switch -c hotfix v1.2.3        # von einem Tag
git branch fixup HEAD~3            # von einer relativen Ref

Die Spitze bewegen

Jeder Commit auf dem aktuellen Branch rückt seine Spitze um eins vor. Befehle, die Spitzen bewegen, sind commit, merge, rebase, reset und cherry-pick.

git commit -m "Work"           # main rückt vor
git reset --hard HEAD~2        # main bewegt sich zurück; Commits werden unerreichbar

Branches und Erreichbarkeit

Ein Commit ist "lebendig", solange ihn irgendeine Ref erreicht. Löschen Sie jeden Branch und Tag, der auf einen Commit zeigt, und er wird dangling; Gits Garbage Collector entfernt ihn schließlich.

git fsck --unreachable
git gc

Upstream tracken

Ein lokaler Branch kann mit einem Remote-Tracking-Branch verknüpft werden:

git branch --set-upstream-to=origin/main main
git branch -u origin/main
git status            # zeigt voraus/zurück basierend auf der Verknüpfung

Branch-Pflege

git branch --merged main           # vollständig gemergte Branches
git branch --no-merged main        # Branches mit ungemergter Arbeit
git branch -d feature/old          # gemergten löschen
git branch -D feature/discarded    # erzwingen-löschen

Branches vergleichen

git log main..feature/login --oneline
git diff main...feature/login
git range-diff main..@{u} main..HEAD

range-diff ist großartig zum Vergleichen zweier Versionen eines rebased Branches.

Branch-Richtlinien auf Hosts

Die meisten Hosting-Plattformen erlauben es, Branches per Namensmuster zu schützen: Pull Requests, signierte Commits, bestandene CI oder bestimmte Reviewer vor Annahme eines Pushes erforderlich machen. Die Git-Seite davon wird über pre-receive-Hooks implementiert; die Plattform-Seite ist Konfiguration. Aus Ihrem lokalen Klon ist der Branch-Schutz unsichtbar, bis Ihr Push abgelehnt wird, woraufhin der Server erklärt, warum. Um den Schutz von der Befehlszeile zu prüfen, verwenden Sie das CLI des Hosts (gh, glab) oder dessen API.

gh api repos/owner/repo/branches/main/protection

Häufige Fehler

Sich Branches als Container von Commits vorstellen. Sind sie nicht; Commits existieren unabhängig, und viele Branches können denselben Commit erreichen. Einen "Feature"-Branch löschen und annehmen, die Commits seien weg; sie sind erst weg, nachdem sie unerreichbar werden und das Reflog abläuft (standardmäßig 90 Tage). Lange einzelwortige Branch-Namen verwenden, die mit Dateinamen kollidieren; ---Trenner vermeiden die Mehrdeutigkeit. Schließlich: Direkt auf main in einem geteilten Repository arbeiten; branchen Sie immer für nicht-triviale Arbeit, auch wenn Sie später per Fast-Forward planen.