02 Übung: Git Pointer und Branches

Einen neuen Branch mit git checkout -b zu erstellen, erzeugt einen neuen Pointer auf denselben Commit, auf dem du dich gerade befindest. Es wird kein neuer Commit erstellt. Sowohl main als auch feature/new-ui zeigen auf Commit i7j8k9l, und HEAD bewegt sich zum neuen Branch. Option B ist falsch, weil kein neuer Commit gemacht wurde. Option C ist falsch, weil main immer noch existiert. Option D ist falsch, weil der Branch keine Commits kopiert - er ist nur ein neuer Pointer auf denselben Commit.

Wenn du einen Commit auf einem Branch machst, erstellt Git einen neuen Commit und bewegt NUR den aktuellen Branch-Pointer vorwärts. Der main-Pointer bleibt bei i7j8k9l, weil wir nicht auf dem main Branch sind. Der neue Commit p9q8r7s wird zur neuen Spitze von feature/new-ui. Option A ist falsch, weil HEAD auf feature/new-ui zeigen sollte. Option B ist falsch, weil sich main bewegt hat (sollte es nicht). Option C ist falsch, weil Commits eine Kette bilden - der neue Commit hat i7j8k9l als Eltern-Commit.

Jeder Commit bewegt den aktuellen Branch-Pointer vorwärts. Nach zwei weiteren Commits zeigt feature/new-ui auf x4y5z6a (den neuesten Commit), während main bei i7j8k9l bleibt (wo wir abgezweigt haben). Die Commits bilden eine lineare Kette: i7j8k9l -> p9q8r7s -> t1u2v3w -> x4y5z6a. Option A ist falsch, weil sich main nicht bewegen sollte. Option C ist falsch, weil die Commit-Kette unterbrochen wird (p9q8r7s muss i7j8k9l als Eltern haben). Option D ist falsch, weil Commit p9q8r7s in der Kette übersprungen wird.

git checkout (oder git switch) bewegt NUR den HEAD-Pointer. Branch-Pointer ändern sich nicht. HEAD bewegt sich davon, auf feature/new-ui zu zeigen, dazu, auf main zu zeigen. Beide Branches existieren weiterhin und zeigen auf ihre jeweiligen Commits. Dein Arbeitsverzeichnis ändert sich, um den Zustand bei Commit i7j8k9l anzuzeigen. Option B ist falsch, weil feature/new-ui immer noch existiert. Option C zeigt die Commits fälschlicherweise als getrennte Ketten. Option D ist falsch, weil main immer noch bei i7j8k9l ist, nicht bei x4y5z6a.

Ein Fast-Forward-Merge bewegt den Ziel-Branch-Pointer (main) vorwärts, um mit dem Quell-Branch (feature/new-ui) übereinzustimmen. Es wird kein Merge-Commit erstellt, weil main einfach zu feature/new-ui „aufholt”. Beide Pointer zeigen jetzt auf denselben Commit x4y5z6a. Option A ist falsch, weil Fast-Forward keinen Merge-Commit erstellt. Option C ist falsch, weil sich main nicht bewegt hat. Option D ist falsch, weil alle Feature-Commits verloren gehen würden.

Tags sind Pointer auf Commits, genau wie Branches. Standardmäßig erstellt git tag einen Tag, der auf den Commit zeigt, auf den HEAD gerade verweist (das ist x4y5z6a, weil HEAD -> main -> x4y5z6a). Der Tag, main und feature/new-ui zeigen jetzt alle auf denselben Commit. Option A ist falsch, weil der Tag auf den aktuellen HEAD-Commit zeigen sollte. Option C ist falsch, weil Tags keine neuen Commits erstellen. Option D zeigt fälschlicherweise getrennte Commit-Ketten.

Wenn man auf main ist und einen Commit macht, bewegt sich nur der main-Pointer vorwärts. Der neue Commit b7c8d9e hat x4y5z6a als Eltern-Commit. feature/new-ui und der Tag v1.0 bleiben weiterhin auf x4y5z6a. Dies erzeugt eine lineare Historie, in der main vorgerückt ist. Option B ist falsch, weil Commits Eltern haben müssen (b7c8d9e sollte x4y5z6a als Eltern haben). Option C ist falsch, weil sich feature/new-ui nicht bewegen sollte (es sollte nicht zweimal erscheinen). Option D ist falsch, weil sie zeigt, dass kein neuer Commit erstellt wurde - main ist immer noch bei x4y5z6a statt beim neuen Commit b7c8d9e.

Die Branches sind vom gemeinsamen Vorfahren x4y5z6a divergiert:

1. Checkout bewegt HEAD: git checkout feature/new-ui bewegt HEAD von main zu feature/new-ui (jetzt bei x4y5z6a)
2. Neuer Commit auf feature/new-ui: Der Commit erstellt f1g2h3i mit Eltern-Commit x4y5z6a (wo feature/new-ui war)
3. Ergebnis: Sowohl b7c8d9e (auf main) als auch f1g2h3i (auf feature/new-ui) zweigen von x4y5z6a ab

Dies erzeugt eine Gabelung in der Historie. Die wichtige Erkenntnis: feature/new-ui zeigte immer noch auf x4y5z6a (es hat sich nicht bewegt, als main den Commit b7c8d9e in F7 bekam), also zweigt der neue Commit f1g2h3i von x4y5z6a ab, NICHT von b7c8d9e.

Option A zeigt eine lineare Historie (f1g2h3i nach b7c8d9e), aber feature/new-ui sollte von x4y5z6a abzweigen. Option C trennt Commits von ihren Eltern. Option D zeigt f1g2h3i als Abzweigung von b7c8d9e, aber feature/new-ui war bei x4y5z6a.

Wenn du einen bestimmten Commit auscheckst (keinen Branch), zeigt HEAD direkt auf diesen Commit statt auf einen Branch-Pointer. Das nennt man „Detached HEAD”-Zustand. Git warnt dich, weil Commits in diesem Zustand zu keinem Branch gehören.

Warum D richtig ist:

• HEAD zeigt jetzt direkt auf Commit x4y5z6a
• HEAD ist als „(detached)” markiert, weil es nicht über einen Branch zeigt
• Die Graph-Struktur ändert sich nicht - Branches bleiben wo sie waren

Warum andere Optionen falsch sind:

• Option A zeigt HEAD immer noch an main angehängt (was bei b7c8d9e geblieben ist)
• Option B zeigt sowohl das Label „main <- HEAD” ALS AUCH main auf x4y5z6a zeigend, was falsch ist - main hat sich nicht bewegt
• Option C lässt die divergierten Commits (b7c8d9e und f1g2h3i) fehlen - das Auschecken eines alten Commits löscht keine neueren Commits!

Das Umbenennen eines Branches ändert nur das Label des Branch-Pointers. Git erstellt einen neuen Pointer mit dem neuen Namen, der auf denselben Commit zeigt, und löscht dann den alten Pointer. Keine Commits werden geändert oder erstellt. Tags wie v1.0 sind davon nicht betroffen, weil sie auf Commits zeigen, nicht auf Branch-Namen. Deshalb ist das Umbenennen von Branches sicher und sofort - du änderst nur ein Label, nicht die eigentliche Historie. Option A ist falsch, weil Commit-Hashes auf dem Inhalt basieren, nicht auf Branch-Namen. Option B ist falsch, weil keine Commits erstellt oder gelöscht werden. Option D ist falsch, weil Tags auf Commits zeigen und von Branch-Namen unabhängig sind.

Remote-Tracking Branches (wie remotes/origin/main) sind lokale Kopien, die als Lesezeichen dienen und anzeigen, was auf GitHub existiert. Sie sind nicht die eigentlichen Remote-Branches - sie sind die Aufzeichnung deines lokalen Gits darüber, was beim letzten Fetch auf GitHub war. Du kannst nicht direkt auf ihnen committen. Option A ist falsch, weil Remote-Tracking Branches schreibgeschützte Lesezeichen sind. Option B ist falsch, weil es keine Remote-Branches sind - es sind lokale Referenzen auf Remote-Branches. Option D ist falsch, weil du nicht auf Remote-Tracking Branches committest; sie werden automatisch durch git fetch oder git pull aktualisiert.

git fetch lädt neue Commits von GitHub herunter und aktualisiert Remote-Tracking Branches (remotes/origin/main), aber es aktualisiert NICHT deine lokalen Branches. Dein lokaler main bleibt bei i7j8k9l, bis du manuell mergst oder git pull verwendest (was fetch + merge ist). Das ist der sichere Weg, um zu sehen, was sich auf GitHub geändert hat, ohne deine Arbeit zu beeinflussen. Option A ist falsch, weil fetch lokale Branches nicht berührt. Option C ist falsch, weil nur das Lesezeichen aktualisiert wird. Option D ist falsch, weil fetch Remote-Tracking Branches SEHR WOHL aktualisiert.

Dein lokales Git hat immer noch die Referenz remotes/origin/feature/old-pr, weil Git Remote-Tracking Branches nicht automatisch entfernt. Sie sind veraltet (zeigen auf einen Branch, der auf GitHub nicht mehr existiert), bis du git fetch --prune oder git remote prune origin ausführst. Das ist beabsichtigt - Git behält Informationen lieber bei. Option A ist falsch, weil die veraltete Referenz bestehen bleibt. Option C ist falsch, weil lokale Branches nicht automatisch gelöscht werden. Option D ist falsch, weil Git Löschungen nicht automatisch erkennt, ohne zu fetchen.

git fetch --prune macht ZWEI Dinge: (1) lädt neue Commits/Branches von GitHub herunter, und (2) entfernt Remote-Tracking Branches, die auf GitHub nicht mehr existieren. Es berührt NICHT deine lokalen Branches - diese musst du separat mit git branch -d löschen. Option A ist falsch, weil lokale Branches von prune nicht betroffen sind. Option C ist falsch, weil --prune eine Ergänzung zu fetch ist, kein Ersatz. Option D ist falsch, weil lokale Branches nie automatisch gelöscht werden.

git pull --prune kombiniert drei Aktionen: (1) git fetch --prune (herunterladen + veraltete Remote-Tracking Branches entfernen), (2) in den aktuellen Branch mergen (main wird per Fast-Forward auf x4y5z6a aktualisiert). Dein LOKALER Branch feature/old-pr wird NICHT gelöscht - das musst du separat mit git branch -d feature/old-pr machen. Nur der Remote-Tracking Branch remotes/origin/feature/old-pr wird durch --prune entfernt. Option A ist falsch, weil der lokale Feature-Branch nicht gezeigt wird. Option B ist falsch, weil lokale Branches nicht automatisch gelöscht werden. Option D ist falsch, weil main sich aktualisiert (das macht pull ja).

Die Vorlesung vergleicht Remote-Tracking Branches mit Browser-Lesezeichen: GitHub ist wie echte Websites, und Remote-Tracking Branches sind deine lokalen Lesezeichen, die auf GitHubs Branches zeigen. Genau wie Lesezeichen veralten können, wenn sich eine Website ändert, werden Remote-Tracking Branches veraltet, wenn sich GitHubs Branches ändern, ohne dass du fetchst. Option A ist falsch, weil es lokale Kopien sind, nicht die eigentlichen Remote-Branches. Option C ist falsch, weil sie den Remote-Zustand verfolgen, keine lokalen Sicherungen. Option D ist falsch, weil sie bestehen bleiben, bis sie explizit bereinigt werden.

Das Ausführen von git config --global fetch.prune true sorgt dafür, dass jedes git fetch und git pull automatisch veraltete Remote-Tracking Branches bereinigt. Dies ist die empfohlene Einstellung aus der Vorlesung, weil es „eine Sache weniger ist, an die man denken muss.” Option B ist keine gültige Git-Konfiguration. Option C ist nicht der richtige Konfigurationsname. Option D setzt das Upstream-Tracking für Branches, was nichts mit Pruning zu tun hat.

git branch --merged main listet alle lokalen Branches auf, deren Commits von main aus erreichbar sind (was bedeutet, dass sie gemergt wurden). Du kannst diese sicher mit git branch -d löschen. Option B zeigt Branches, die NOCH NICHT gemergt wurden (das Gegenteil von dem, was du willst). Option C zeigt Remote-Tracking Branches, die bereinigt würden, nicht lokale Branches. Option D ist kein gültiges git log Flag.

„Squash and merge” erstellt einen NEUEN Commit, der alle deine Änderungen zusammenfasst, anstatt deine ursprünglichen Commits zu verwenden. Git sieht deine lokalen Commits als „nicht gemergt”, weil sie nicht in der Historie von main existieren (nur die gesquashte Version). Nachdem du auf GitHub bestätigt hast, dass der PR tatsächlich gemergt wurde, ist es sicher, mit git branch -D feature/squashed zwangsweise zu löschen. Option B ist falsch - der PR IST gemergt, nur in einer anderen Form. Option C ist falsch - Rebase hilft hier nicht. Option D ist falsch - du kannst und solltest gemergte Branches löschen.

Der komplette Workflow ist: (1) git checkout main um zu main zu wechseln, (2) git pull --prune um main zu aktualisieren UND veraltete Remote-Tracking Branches zu entfernen, (3) git branch -d feature/xyz um deinen lokalen Branch zu löschen. Das bereinigt alle drei: lokalen Branch, lokalen main und veraltete Remote-Tracking Referenzen. Da der PR mit „Create a merge commit” (nicht Squash) gemergt wurde, erkennt Git den Branch als gemergt und -d funktioniert sicher. Option A ist falsch, weil main nicht aktualisiert und nicht bereinigt wird. Option B ist falsch, weil der lokale Branch nicht gelöscht wird. Option D ist falsch, weil main nicht aktualisiert wird und Force Delete (-D) verwendet wird, was unnötig ist, wenn der Branch ordnungsgemäß gemergt wurde.