Git Branches als Zeiger

Beispiel 1: Vor dem Erstellen des Branches

Zustand am 21.10.2025 um 16:26:11 (auf main)

• beaea6c ist der tatsächliche Commit (Snapshot: "remove C$ from ruff settings")
• main ist ein Branch-Zeiger, der auf Commit beaea6c zeigt
• HEAD zeigt auf main (du bist gerade auf dem main-Branch)
• lecture-01 Tag zeigt auf Commit 92c2df3

Beispiel 1: Erstellen des Branches

Befehl:

$ git checkout -b feauture/fix_code_quality
# (Hinweis: hatte ursprünglich den Tippfehler!)

Nach dem Erstellen des Branches:

Beispiel 1: Was ist gerade passiert?

1. Git hat einen NEUEN Zeiger namens feauture/fix_code_quality erstellt
2. Dieser Zeiger zeigt auf den GLEICHEN Commit wie main (beaea6c)
3. Git hat HEAD verschoben, um auf den neuen Branch zu zeigen
4. Keine Commits wurden erstellt oder kopiert - nur ein neuer Zeiger!

Wichtige Erkenntnis: Das Erstellen eines Branches ist günstig - es ist nur das Erstellen eines Zeigers (ein paar Bytes)!

Beispiel 2: Erster Commit auf dem Branch

Den ersten Commit erstellen:

$ vim main.py  # Code-Formatierung reparieren
$ git add main.py
$ git commit -m "fix code formatting using ruff format"

Vor dem Commit:

Beispiel 2: Nach dem ersten Commit

Nach dem Commit (032f36c):

Was ist passiert:

1. Git hat einen NEUEN Commit 032f36c erstellt
2. Git hat den feauture/fix_code_quality-Zeiger vorwärts zu 032f36c bewegt
3. Der main-Zeiger blieb bei beaea6c (unverändert!)
4. HEAD zeigt immer noch auf feauture/fix_code_quality

Beispiel 2: Wichtige Erkenntnis

Nur der aktuelle Branch-Zeiger bewegt sich, wenn du commitest.

Andere Branches bleiben, wo sie sind!

So bieten Feature-Branches Isolation - deine Arbeit auf dem Feature-Branch beeinflusst main nicht.

Beispiel 3: Nach mehreren Commits

Weitere Commits erstellen:

$ git commit -m "lasse ruff check laufen..."  # e341990
$ git commit -m "style: fix code quality..."  # 1ff0a77

Finaler Zustand nach 3 Commits auf dem Branch:

Beispiel 3: Die Divergenz visualisieren

Was wir sehen:

• main ist immer noch bei beaea6c (wo wir abgezweigt sind)
• feauture/fix_code_quality ist durch 3 Commits vorwärts gegangen
• Die Arbeit am Feature-Branch ist isoliert von main
• HEAD zeigt auf den Feature-Branch (wir arbeiten daran)

Beispiel 4: Zwischen Branches wechseln

Zurück zu main wechseln:

$ git checkout main

Beispiel 4: Was hat sich geändert?

Nur HEAD hat sich bewegt!

• HEAD ist vom Feature-Branch-Zeiger zum Main-Zeiger gewechselt
• Dein Arbeitsverzeichnis hat sich geändert, um Commit beaea6c zu zeigen
• Die Branch-Zeiger selbst haben sich nicht bewegt
• feauture/fix_code_quality zeigt immer noch auf 1ff0a77

Das ist alles, was git checkout macht - es bewegt den HEAD-Zeiger!

Beispiel 5: Feature-Branch in Main mergen

Wenn du den Feature-Branch mergst:

$ git checkout main
$ git merge feauture/fix_code_quality
# (Oder merge über GitHub PR)

Ergebnis: Fast-Forward-Merge

Beispiel 5: Nach dem Merge

Nach dem Merge (Fast-Forward):

Was ist passiert:

• Git hat den main-Zeiger vorwärts zu 1ff0a77 bewegt
• Das ist ein "Fast-Forward"-Merge (main holt nur auf)
• Sowohl main als auch feauture/fix_code_quality zeigen jetzt auf denselben Commit
• Kein Merge-Commit war nötig (lineare Historie)

Beispiel 6: Einen Tag hinzufügen

Den lecture-04 Tag erstellen:

$ git tag -a lecture-04 -m "End of Chapter 02 (Refactoring): Code quality fixes"

Aktueller Zustand mit Tag:

Alle vier Zeiger zeigen auf den GLEICHEN Commit 1ff0a77!

Beispiel 6: Tags sind auch Zeiger

Tags sind genau wie Branches - sie sind Zeiger auf Commits!

Der Unterschied:

• Branch-Zeiger bewegen sich vorwärts, wenn du commitest
• Tag-Zeiger bewegen sich nie (permanente Markierungen)

Beide sind nur Referenzen auf Commits - keine Kopien von Commits.

Beispiel 7: Den Branch umbenennen

Den Tippfehler korrigieren:

$ git branch -m feauture/fix_code_quality feature/fix_code_quality

Was ist passiert:

Beispiel 7: Der Commit hat sich nie geändert

Der Commit 1ff0a77 hat sich nie geändert!

Wir haben nur:

1. Einen neuen Zeiger mit der korrekten Schreibweise erstellt
2. Den alten Zeiger mit dem Tippfehler gelöscht

Deshalb:

• Der Tag lecture-04 funktioniert immer noch (zeigt auf Commit, nicht auf Branch-Namen)
• Jeder, der den Tag ausgecheckt hat, hat den Tippfehler nie gesehen
• Branches sind nur Labels, nicht der eigentliche Code

Zusammenfassung: Branches als Zeiger

Wichtige Erkenntnisse:

1. Commits sind die tatsächlichen Snapshots (ändern sich nie, sobald sie erstellt wurden)
2. Branches sind leichtgewichtige, bewegliche Zeiger auf Commits
3. Tags sind leichtgewichtige, permanente Zeiger auf Commits
4. HEAD ist ein spezieller Zeiger, der "Du bist hier" anzeigt

Wenn du:

• Einen Branch erstellst → Erstelle einen neuen Zeiger
• Einen Commit machst → Bewege den aktuellen Branch-Zeiger vorwärts
• Branches wechselst → Bewege HEAD zu einem anderen Branch-Zeiger
• Branches mergst → Bewege den Ziel-Branch-Zeiger vorwärts
• Einen Branch umbenennst → Erstelle neuen Zeiger, lösche alten

Warum das wichtig ist

Das Verstehen von Branches als Zeiger hilft dir:

1. Git-Befehle verstehen - Wisse, was wirklich passiert
2. Selbstbewusst arbeiten - Keine Angst, Dinge zu "kaputt" zu machen
3. Probleme debuggen - Verstehe, wo du bist und warum
4. Erweiterte Features nutzen - Rebase, Cherry-Pick, etc.

Git wird weniger magisch und logischer!

Praktische Anwendung

In deinem täglichen Workflow:

# Einen Branch erstellen? Nur einen Zeiger erstellen!
$ git checkout -b feature/new-feature

# Commits machen? Den Branch-Zeiger vorwärts bewegen!
$ git commit -m "Add feature"

# Branches wechseln? HEAD bewegen!
$ git checkout main

# Mergen? Den Ziel-Branch-Zeiger bewegen!
$ git merge feature/new-feature

Jeder Git-Befehl manipuliert nur diese Zeiger!

Fragen?

Merke dir:

• Branches ≠ Commits
• Branches = Zeiger auf Commits
• Deshalb sind Branches schnell, günstig und mächtig!

Probiere es selbst:

$ git log --oneline --graph --all --decorate

Sieh alle Zeiger (Branches, Tags, HEAD) und auf welche Commits sie zeigen!

Zusätzliche Ressourcen

Aus der Vorlesungsdatei:

• Abschnitt 4.2: Die technische Realität: Branches sind Zeiger
• Abschnitt 4.3: Warum Branches verwenden?

Interaktives Lernen:

• Learn Git Branching - Visuelles, interaktives Tutorial

Offizielle Dokumentation:

• Git Branching - Branches in a Nutshell