In Git sind Branches bewegliche Zeiger, die auf spezifische Commits
verweisen. Ein Branch ist also kein eigenständiges Objekt, sondern ein
einfaches Label, das an einen Commit angehängt wird. Branches
ermöglichen paralleles Arbeiten an verschiedenen Features oder
Korrekturen, ohne den Hauptentwicklungszweig zu beeinträchtigen.
11.1.1 Eigenschaften von
Branches
Beweglichkeit von Branches: Ein Branch bewegt sich
bei jedem neuen Commit automatisch auf den neuen Snapshot. Dies
unterscheidet Branches von Tags, die fest mit einem spezifischen Commit
verknüpft sind und sich nicht bewegen.
Leichtgewichtige Referenzen: Da ein Branch
lediglich ein Zeiger auf einen Commit ist, handelt es sich um ein
leichtgewichtiges Konzept. Es entstehen keine zusätzlichen Kopien der
Dateien, wenn ein neuer Branch erstellt wird.
Trennung von Entwicklungssträngen: Branches werden
genutzt, um verschiedene Entwicklungslinien zu verfolgen. Typische
Verwendungen sind Feature-Branches, die für die Entwicklung neuer
Funktionen erstellt werden, oder Bugfix-Branches.
11.1.2 Branches und Tags im
Vergleich
Branches: Bewegliche Zeiger, die mit neuen Commits
voranschreiten.
Tags: Feste, unveränderliche Marker, die einem
bestimmten Commit zugeordnet sind und als feste Referenzpunkte, z. B.
für Versionsnummern, dienen.
11.2 Erstellung und Nutzung von
Branches
Ein Branch wird mit dem Befehl git branch erstellt:
git branch <branchname>
Das Verschieben zu einem Branch erfolgt mit git checkout
oder git switch:
git checkout <branchname>
Mit jedem neuen Commit auf diesem Branch wird der Zeiger des Branches
auf den neuen Commit verschoben. Dies macht Branches in Git so flexibel
und beweglich.
11.3 Merging in Git
Das Zusammenführen (Merging) von Branches ist der Prozess, bei dem
zwei oder mehr Entwicklungsstränge zu einem vereinigt werden. Es gibt
zwei Haupttypen von Merges:
Fast-Forward Merge: Dieser Merge-Typ findet statt,
wenn keine neuen Commits im Ziel-Branch existieren, seit der
Quell-Branch erstellt wurde. Git kann in diesem Fall einfach den Zeiger
des Ziel-Branches auf den letzten Commit des Quell-Branches verschieben,
da kein echter Merge erforderlich ist.
Three-Way Merge: Wenn beide Branches eigene Commits
enthalten, die in den anderen Branch noch nicht integriert sind, führt
Git einen Three-Way-Merge durch. Dieser Merge-Typ vergleicht den
gemeinsamen Vorfahren der beiden Branches und vereint die Änderungen aus
beiden Branches in einem neuen Commit.
11.4 Konflikte beim Merging
Konflikte treten auf, wenn Git Änderungen nicht automatisch
zusammenführen kann, da sie sich in derselben Datei überschneiden. In
einem solchen Fall muss der Entwickler die Konflikte manuell lösen,
bevor der Merge abgeschlossen werden kann.
11.5 Rebasing
Rebasing ist ein alternativer Ansatz zum Merging, bei dem die Commits
eines Branches auf einem neuen Basiskommit “neu aufgesetzt” werden. Das
Ergebnis ist eine lineare Historie ohne Merge-Commits. Beim Rebase wird
die Commithistorie des aktuellen Branches auf die Spitze eines anderen
Branches verschoben.
Der Rebase-Prozess verläuft in zwei Schritten:
Git entfernt die Commits des aktuellen Branches, bis es den
gemeinsamen Vorfahren des Ziel-Branches erreicht.
Git wendet die entfernten Commits in der Reihenfolge erneut an, aber
mit dem Ziel-Branch als neue Basis.
Rebase kann verwendet werden, um eine klare, lineare Historie zu
behalten, insbesondere in Projekten, die eine saubere Commit-Historie
erfordern.
11.5.1 Unterschiede zwischen
Merging und Rebasing
Merging: Behält die gesamte Historie bei,
einschließlich der Merge-Commits, was zu einer verzweigten Historie
führt.
Rebasing: Erzeugt eine lineare Historie, indem
Commits auf eine neue Basis gesetzt werden, was die Historie sauberer
erscheinen lässt.
