CodeGym /Kurse /C# SELF /Sichere Experimente: Arbeiten mit Branches

Sichere Experimente: Arbeiten mit Branches

C# SELF
Level 26 , Lektion 2
Verfügbar

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"
        
Vom Haupt-Branch 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:

  1. Du hast eine fertige Manuskriptversion (das ist dein Haupt-Branch main).
  2. Du willst ein alternatives Ende schreiben (du erstellst einen neuen Branch, z. B. feature/new-idea).
  3. Du schreibst das neue Ende, ohne den Haupttext zu verändern (du arbeitest im neuen Branch).
  4. Wenn das neue Ende besser ist, ersetzt du das alte damit (du machst ein Merge — merge).
  5. 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"
        
Beide Branches, 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:

  1. Stelle sicher, dass du im Branch main bist und keine ungespeicherten Änderungen hast.
  2. Erstelle sofort einen neuen Branch feature/new-title, aber wechsel noch nicht darauf. Achte darauf, dass das Häkchen bei Checkout branch entfernt ist.
  3. Bleib im Branch main und ändere die erste Zeile in README.md zu "My Awesome Project" und mach einen commit.
  4. Wechsle auf den Branch feature/new-title. Du wirst sehen, dass die erste Zeile in README.md hier alt geblieben ist: das ist der Zustand der Datei beim Erstellen des Branches. ändere dieselbe Zeile zu "My Super Project" und mach einen commit.
  5. Geh zurück in den Branch main und führe ein Merge mit feature/new-title aus.

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:

  1. Du hast einen Commit in main (sagen wir C1).
  2. Du machst einen neuen Commit in main mit dem Text "My Awesome Project". Der Branch main zeigt jetzt auf Commit C2 (main -> C1 -> C2).
  3. Du erstellst den Branch feature/new-title aus der aktuellen Position von main. Das heißt, der neue Branch beginnt auch bei Commit C2.
  4. Du machst einen Commit in feature/new-title mit dem Text "My Super Project". Dieser Branch "läuft vor" und zeigt jetzt auf Commit C3 (feature/new-title -> C1 -> C2 -> C3).
  5. 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!

Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION