Umfassender Leitfaden zu Git-Branching: Erstellen, Wechseln, Löschen

Git-Branching ermöglicht es Ihnen, an einer Funktion, einem Fix oder einem Experiment zu arbeiten, ohne die Hauptentwicklungslinie zu stören. Eine gute Branching-Gewohnheit hält Ihre Änderungen organisiert und macht Reviews, Tests und Rollbacks viel einfacher.

Branches sind leichtgewichtige Zeiger auf Commits. Das bedeutet, dass das Erstellen, Wechseln und Löschen schnell ist, aber die Entscheidungen, die Sie treffen, beeinflussen dennoch, wie klar Ihre Projekthistorie lesbar ist.

Was ein Git-Branch ist

Ein Git-Branch ist ein beweglicher Name, der auf einen Commit zeigt. Wenn Sie neue Arbeit auf einem Branch committen, bewegt Git diesen Branchnamen zum neuen Commit weiter.

Die meisten Projekte haben einen primären Branch wie main oder master. Teams halten diesen Branch normalerweise stabil und erstellen dann kurzlebige Branches für spezifische Arbeiten:

git switch -c fix-login-timeout

Dies erstellt einen neuen Branch und wechselt zu ihm. Ältere Git-Beispiele verwenden möglicherweise:

git checkout -b fix-login-timeout

Beide Muster sind üblich, aber git switch ist leichter zu lesen, da es sich nur auf die Branch-Bewegung konzentriert.

Branchnamen sollten spezifisch genug sein, um die Arbeit zu erklären. feature ist zu vage. feature/add-health-check-endpoint oder fix/nginx-502-upstream-timeout ist viel besser. Ein klarer Name hilft Ihnen und Ihren Reviewern, den Branch zu verstehen, bevor Sie Dateien öffnen.

Erstellen und Wechseln von Branches

Bevor Sie einen Branch erstellen, beginnen Sie von der richtigen Basis. Für die meisten Teams bedeutet das, zuerst Ihren primären Branch zu aktualisieren:

git switch main
git pull
git switch -c feature/add-metrics-endpoint

Dies reduziert die Wahrscheinlichkeit, dass Ihr neuer Branch von veraltetem Code ausgeht. Es beseitigt keine Konflikte, gibt Ihnen aber einen saubereren Startpunkt.

Um lokale Branches aufzulisten, führen Sie aus:

git branch

Der aktuelle Branch hat ein Sternchen daneben. Um auch entfernte Branches zu sehen, verwenden Sie:

git branch -a

Um zu einem vorhandenen Branch zu wechseln:

git switch branch-name

Wenn der Branch nur auf dem Remote existiert, können Sie normalerweise einen lokalen Tracking-Branch erstellen mit:

git switch --track origin/branch-name

Tracking ist wichtig, weil es Ihren lokalen Branch mit seinem entfernten Gegenstück verbindet. Sobald das Tracking eingerichtet ist, wissen einfache Befehle wie git pull und git push, welchen entfernten Branch sie verwenden sollen.

Stellen Sie sich ein konkretes Szenario vor: Sie müssen einen Jenkins-Pipeline-Fehler beheben, während Sie gleichzeitig an einer größeren Docker-Image-Bereinigung arbeiten. Legen Sie diese Änderungen auf separate Branches. Der dringende Patch kann schnell überprüft und gemerged werden, während die größere Bereinigung ohne Blockierung fortgesetzt werden kann.

Für verwandte Grundlagen siehe Erste Schritte mit Git-Repositories.

Branches organisiert halten

Branches werden unübersichtlich, wenn sie zu lange offen bleiben oder nicht zusammenhängende Änderungen sammeln. Der beste Branch ist normalerweise klein, fokussiert und leicht zu überprüfen.

Verwenden Sie einen Branch für einen Zweck:

• Ein Bugfix-Branch sollte den Fix und alle zugehörigen Tests enthalten.
• Ein Feature-Branch sollte das Feature enthalten, keine beiläufigen Refactorings.
• Ein Bereinigungs-Branch sollte Verhaltensänderungen vermeiden, es sei denn, sie sind eindeutig Teil der Bereinigung.

Überprüfen Sie vor dem Pushen Ihre Arbeit:

git status
git diff --staged

Dies fängt versehentliche Dateien und nicht zusammenhängende Bearbeitungen ab. Es ist besonders nützlich in DevOps-Repositories, in denen generierte Dateien, lokale Konfigurationen und Secret-Vorlagen in der Nähe von echten Quelldateien liegen können.

Wenn Ihr Branch die neuesten Änderungen von main benötigt, haben Sie zwei gängige Optionen:

git merge main

oder:

git rebase main

Merge bewahrt die genaue Branch-Historie. Rebase schreibt Ihre Branch-Commits auf die neueste Basis um. Beide sind nützlich, aber Teams sollten sich darauf einigen, welchen Stil sie erwarten, bevor sie gemeinsame Arbeit mergen. Wenn Sie unsicher sind, bevorzugen Sie den von Ihrem Projekt dokumentierten Workflow.

Branches sicher löschen

Das Löschen alter Branches hält Ihr Repository leichter navigierbar. Nachdem ein Branch gemerged wurde, löschen Sie die lokale Kopie mit:

git branch -d branch-name

Das kleingeschriebene -d ist die sicherere Option. Git weigert sich, den Branch zu löschen, wenn es glaubt, dass die Arbeit nicht gemerged wurde.

Wenn Sie wirklich einen nicht gemergten lokalen Branch löschen müssen, verwenden Sie:

git branch -D branch-name

Verwenden Sie dies vorsichtig. Es entfernt den Branchnamen, selbst wenn die Commits nicht gemerged sind. Die Commits können möglicherweise eine Weile über das Reflog wiederhergestellt werden, aber Sie sollten dies nicht als normales Sicherheitsnetz betrachten.

Um einen entfernten Branch zu löschen:

git push origin --delete branch-name

Löschen Sie entfernte Branches nur, wenn die Arbeit gemerged, aufgegeben oder eindeutig von Ihnen besessen ist. In gemeinsamen Teams können entfernte Branches von Reviews, Deployment-Vorschauen oder anderen Entwicklern verwendet werden.

Sie können veraltete entfernte Tracking-Referenzen bereinigen mit:

git fetch --prune

Dies entfernt lokale Referenzen auf entfernte Branches, die auf dem Server nicht mehr existieren. Es löscht keine echten entfernten Branches.

Wann Sie einen Teammitglied fragen sollten

Das Erstellen und Wechseln von Branches sind risikoarme Operationen. Die riskanten Momente sind das Löschen nicht gemergter Arbeit, Force-Pushing und das Rebasing von Branches, die andere Personen möglicherweise bereits verwenden.

Fragen Sie, bevor Sie Force-Push auf einen gemeinsamen Branch durchführen. Fragen Sie auch, bevor Sie einen entfernten Branch löschen, den Sie nicht erstellt haben. In CI/CD-lastigen Repositories kann ein Branch Builds, Vorschauen oder Deployment-Regeln auslösen, die aus Git allein nicht ersichtlich sind.

Gutes Branching dreht sich hauptsächlich um Klarheit. Erstellen Sie einen Branch von der richtigen Basis, benennen Sie ihn nach der Arbeit, halten Sie ihn fokussiert und löschen Sie ihn, wenn er nicht mehr benötigt wird. Diese Gewohnheiten machen Git für Sie einfacher und für das gesamte Team sicherer.