1. Was sind Branches und wozu braucht man sie?
Arbeiten mit branches in Git — das ist einer der zentralen Aspekte der Versionsverwaltung, der es erlaubt, mehrere Entwicklungslinien parallel in einem Repository zu führen. Branching macht Git zu einem mächtigen Tool für Kollaboration, Experimente und das Management verschiedener Projektversionen.
gitGraph
commit id: "Initial setup"
commit id: "Add base features"
branch feature/new-idea
checkout feature/new-idea
commit id: "Implement new logic"
commit id: "Refactor the logic"
checkout main
commit id: "Urgent bugfix on main"
merge feature/new-idea
commit id: "Prepare for release"
main geht ein neuer Branch
feature/new-idea für sichere Entwicklung ab. Nach Abschluss wird er wieder in
main gemerged.
Stell dir vor, du willst etwas Großes an deinem Projekt umbauen oder ein riskantes Experiment durchführen. Wie würdest du das ohne Git machen? Wahrscheinlich würdest du das ganze Projekt in einen neuen Ordner kopieren und dort arbeiten. Wenn das Ergebnis gefällt — kopierst du es zurück in den Hauptordner. Wenn nicht — löscht du einfach die Kopie.
Branches in Git funktionieren nach dem gleichen Prinzip, aber viel eleganter. Schauen wir uns das am Beispiel des Schreibens eines Buches an:
- Du hast eine fertige Manuskriptversion (das ist dein Haupt-Branch
main). - Du willst ein alternatives Ende schreiben (du erstellst einen neuen Branch, z. B.
feature/new-idea). - Du schreibst das neue Ende, ohne den Haupttext zu verändern (du arbeitest im neuen Branch).
- Wenn das neue Ende besser ist, ersetzt du das alte damit (du machst ein Merge —
merge). - Den alten Entwurf mit dem unnötigen Ende kannst du löschen (du löschst den Branch).
2. Einen neuen Branch erstellen und darin arbeiten
Schritt 1. Öffne das Branch-Management-Menü.
In der oberen Leiste der IDE gibt es ein Widget, das den Namen des aktuellen Branches anzeigt (standardmäßig — main). Klick darauf und wähle + New Branch.
Schritt 2. Name des neuen Branches.
Gute Praxis ist, Branches nach der Aufgabe zu benennen, an der du arbeitest. Zum Beispiel feature/add-usage-examples.
Nach dem Erstellen wechselt die IDE automatisch auf den neuen Branch. Du siehst den neuen Namen im selben Widget.
Schritt 3. Mach Änderungen und committe sie.
Jetzt bist du in deiner "Sandkiste". Fügen wir in unsere Datei README.md einen neuen Abschnitt mit Usage-Beispielen hinzu. Nimm die Änderungen vor und mach einen commit, wie du es in einer früheren Vorlesung gelernt hast.
3. Zwischen Branches wechseln
Deine Änderungen mit den Usage-Beispielen sind jetzt sicher im Branch feature/add-usage-examples gespeichert. Lass uns zurück zum Haupt-Branch main gehen und schauen, was dort ist.
Schritt 1. Klick wieder auf das Widget mit dem aktuellen Branch-Namen.
Schritt 2. Wähle in der Liste Local oder Recent den Branch main und klicke im aufklappenden Menü auf Checkout.
Schritt 3. Überprüfe das Ergebnis.
Sobald du gewechselt hast, öffne die Datei README.md. Du wirst sehen, dass der Abschnitt mit Usage-Beispielen dort fehlt! Er ist im anderen Branch geblieben. So kannst du an neuer Funktionalität arbeiten, ohne die stabile Version im Branch main zu beeinflussen.
4. Branches mergen (Merge)
Der Befehl merge nimmt alle Commits aus dem Branch feature/add-examples (in diesem Beispiel Commit C3) und vereinigt sie mit dem aktuellen Branch main, wobei ein neuer Merge-Commit erstellt wird.
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/add-examples
checkout feature/add-examples
commit id: "C3: Add new section"
checkout main
merge feature/add-examples
Also, du hast deine Aufgabe im Branch feature/add-usage-examples abgeschlossen und willst diese Änderungen ins Hauptprojekt übernehmen.
Schritt 1. Wechsle zum Ziel-Branch.
Stelle sicher, dass du dich in dem Branch befindest, IN DENEN du die Änderungen aufnehmen möchtest. In unserem Fall ist das main.
Schritt 2. Führe den Merge aus.
Klick wieder auf das Branch-Management-Widget. Wähle in der Liste den Branch, VON DEM du die Änderungen holen willst (feature/add-usage-examples), und wähle im Untermenü Merge feature/add-usage-examples in main aus.
Schritt 3. Überprüfe das Ergebnis.
Jetzt ist in der Datei README.md im Branch main dein neuer Abschnitt mit Usage-Beispielen aufgetaucht. Du hast deine Arbeit erfolgreich mit der Hauptversion des Projekts zusammengeführt!
5. Merge-Konflikte: keine Angst, das ist normal!
Manchmal treten beim Mergen von Branches Konflikte auf. Das passiert, wenn in beiden Branches dieselben Zeilen in derselben Datei geändert wurden. Git kann nicht automatisch entscheiden, welche Version korrekt ist, und bittet dich um Hilfe.
gitGraph
commit id: "C1: Gemeinsame Basis"
branch feature/new-title
checkout main
commit id: "C2: Änderung in main"
checkout feature/new-title
commit id: "C3: Änderung in feature"
main und
feature/new-title, haben neue Commits (C2 und C3), die auf einem gemeinsamen Vorfahren (C1) basieren. Das führt garantiert zu einem Konflikt beim Merge.
Lass uns einen Konflikt simulieren:
- Stelle sicher, dass du im Branch
mainbist und keine ungespeicherten Änderungen hast. - Erstelle sofort einen neuen Branch
feature/new-title, aber wechsel noch nicht darauf. Achte darauf, dass das Häkchen bei Checkout branch entfernt ist. - Bleib im Branch
mainund ändere die erste Zeile inREADME.mdzu "My Awesome Project" und mach einencommit. - Wechsle auf den Branch
feature/new-title. Du wirst sehen, dass die erste Zeile inREADME.mdhier alt geblieben ist: das ist der Zustand der Datei beim Erstellen des Branches. ändere dieselbe Zeile zu "My Super Project" und mach einencommit. - Geh zurück in den Branch
mainund führe ein Merge mitfeature/new-titleaus.
Nun erkennt Git, dass beide Branches neue, auseinanderlaufende Historien vom gemeinsamen Vorfahren haben. In beiden Historien wurde dieselbe Zeile geändert, daher kann Git nicht automatisch wählen, welche Version die richtige ist, und zeigt dir ein Fenster zur Konfliktauflösung.
Merge Revision
Was du hier siehst:
- Links (Your changes): die Version der Datei aus deinem aktuellen Branch (
main). - Rechts (Changes from branch...): die Version der Datei aus dem Branch, den du mergst.
- In der Mitte (Result): die finale Version der Datei, die du zusammenstellen musst.
Du kannst auf die Pfeile >> oder << klicken, um komplett die eine oder andere Variante zu übernehmen.
Wenn das Ergebnis in der mittleren Leiste für dich passt, klick auf Apply. Die IDE erstellt dann automatisch den Merge-Commit und der Konflikt ist gelöst.
Warum ist kein Konflikt aufgetreten?
Es kann passieren, dass du alle Schritte gemacht hast und kein Konflikt auftritt. Meistens liegt das daran, dass Git einen fast-forward merge durchführen konnte, weil die Historie eines Branches einfach die Historie des anderen fortgesetzt hat. Damit ein Konflikt sicher auftritt, müssen sich die Branch-Historien vom gemeinsamen Vorfahren in unterschiedliche Richtungen entwickeln.
Beispiel:
- Du hast einen Commit in
main(sagen wir C1). - Du machst einen neuen Commit in
mainmit dem Text "My Awesome Project". Der Branchmainzeigt jetzt auf Commit C2 (main -> C1 -> C2). - Du erstellst den Branch
feature/new-titleaus der aktuellen Position von main. Das heißt, der neue Branch beginnt auch bei Commit C2. - Du machst einen Commit in
feature/new-titlemit dem Text "My Super Project". Dieser Branch "läuft vor" und zeigt jetzt auf Commit C3 (feature/new-title -> C1 -> C2 -> C3). - Du gehst zurück zu
main(das immer noch auf C2 steht) und forderst, feature/new-title zu mergen.
Git schaut und sieht, dass der Branch main ein direkter Vorfahre des Branches feature/new-title ist. In der Geschichte von main gab es keine neuen Commits, während du in dem anderen Branch gearbeitet hast. Git denkt: "Ah, hier muss ich main einfach bis zu Commit C3 vorspulen. Keine Konflikte." Und verschiebt einfach den Pointer main auf Commit C3.
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/new-title
checkout feature/new-title
commit id: "C3"
checkout main
merge feature/new-title
6. Verlauf der Änderungen anschauen
Um besser zu verstehen, was in deinem Projekt vor sich geht, ist es nützlich, die Historie anzuschauen.
Öffne den Tab Git unten in der IDE und wähle Log. Du siehst eine grafische Darstellung aller Branches und Commits. Das hilft dir, anschaulich nachzuvollziehen, welcher Branch von welchem abgezweigt wurde und wo sie gemerged wurden.
Hier kannst du auf jeden Commit klicken, um zu sehen, welche Änderungen darin enthalten sind, wer und wann ihn gemacht hat. Das ist eine echte Zeitmaschine für Code!
GO TO FULL VERSION