Einführung
Stellen Sie sich vor, Sie schreiben eine Geschichte. Sie erreichen eine Stelle, an der sich die Handlung in zwei Richtungen entwickeln kann: Der Held kämpft gegen den Drachen oder freundet sich mit ihm an. Sie möchten beide Versionen schreiben, um herauszufinden, welche besser ist, aber Ihr Hauptmanuskript soll dabei unverändert bleiben.
In Git ermöglicht Branching genau das. Es erstellt eine parallele Entwicklungslinie, in der Sie sicher experimentieren können. Branches gehören zu den wichtigsten Konzepten in Git, weil isoliertes Arbeiten dadurch einfach und unkompliziert wird.
Ein Branch ist in Git keine vollständige Kopie des Projekts. Er ist hauptsächlich ein verschiebbarer Zeiger auf eine Folge von Commits. Deshalb lassen sich Branches schnell und mit geringem Ressourcenaufwand erstellen.
- Funktionen entwickeln: Entwickeln Sie ein neues Anmeldesystem in einem separaten Bereich.
- Experimentieren: Testen Sie eine neue Designidee, ohne die aktuelle Website zu beschädigen.
- Fehler beheben: Beheben Sie einen kritischen Fehler isoliert.
In diesem Lab erstellen Sie eine parallele Zeitlinie (einen Branch), nehmen darin Änderungen vor und wechseln anschließend zurück zur Hauptzeitlinie. So weisen Sie nach, dass Ihre Experimente das ursprüngliche Projekt nicht beeinflusst haben.
Einen Feature-Branch erstellen
Standardmäßig beginnt jedes Git-Repository mit einem Haupt-Branch, der normalerweise master oder main heißt. Stellen Sie sich diesen Branch als die „primäre Zeitlinie“ vor – die offizielle, stabile Version Ihres Projekts.
Wenn Sie an einer neuen Funktion, beispielsweise einer Anmeldeseite, arbeiten möchten, ohne die Stabilität des Hauptprojekts zu gefährden, erstellen Sie einen neuen Branch.
Überprüfen Sie Ihre aktuelle Position:
git branch
Ausgabe:
* master
Das * zeigt an, dass Sie sich aktuell auf der Zeitlinie master befinden.
Diese Markierung zeigt Ihren aktuellen Branch-Kontext. Viele Git-Befehle beziehen sich auf den Branch, auf den HEAD aktuell zeigt. Deshalb ist es wichtig zu wissen, wo Sie sich befinden.
Erstellen Sie einen neuen Branch mit dem Namen feature_login:
git branch feature_login
Sie haben jetzt eine neue Zeitlinie erstellt. Sie befinden sich jedoch noch nicht auf diesem Branch.
Das verdeutlicht einen wichtigen Unterschied in Git: Einen Branch zu erstellen und zu einem Branch zu wechseln sind zwei getrennte Aktionen. Ein Branch kann existieren, ohne dass er Ihr aktueller Arbeitskontext ist.
Überprüfen Sie, ob der Branch erstellt wurde:
git branch
Ausgabe:
feature_login
* master
Der Branch feature_login existiert, aber das * zeigt, dass Sie sich weiterhin auf master befinden.
Zum neuen Branch wechseln
Eine neue Zeitlinie zu erstellen reicht nicht aus. Sie müssen auch zu ihr wechseln. Der Befehl zum Wechseln zwischen Branches lautet git checkout.
Wechseln Sie zu Ihrem neuen Branch:
git checkout feature_login
Ausgabe:
Switched to branch 'feature_login'
Überprüfen Sie, ob der Wechsel erfolgreich war:
git branch
Ausgabe:
* feature_login
master
Das Sternchen (*) ist gewandert. Sie arbeiten jetzt innerhalb der Zeitlinie feature_login. Alle Änderungen, die Sie ab jetzt vornehmen, geschehen nur in diesem Branch.
Genauer gesagt, werden neue Commits den Branch feature_login weiterentwickeln und nicht master. Beide Branches teilen weiterhin die bisherige Historie bis zu dem Punkt, an dem sie auseinanderlaufen.
Im Feature-Branch arbeiten
Jetzt befinden Sie sich in einem sicheren Experimentierbereich. Schreiben wir etwas Code. Wir erstellen ein Skript für unsere „Anmeldefunktion“.
Erstellen Sie eine Datei mit dem Namen login.sh:
echo "echo 'Logging in...'" > login.sh
Überprüfen Sie, ob die Datei in Ihrem Verzeichnis vorhanden ist:
ls
Sie sollten sowohl README.md (aus master übernommen) als auch die neue Datei login.sh sehen.
Zu diesem Zeitpunkt ist login.sh lediglich eine Datei auf Ihrer Festplatte. Damit sie dauerhaft in der Historie dieses Branches gespeichert wird, müssen Sie sie committen.
Das verdeutlicht erneut das Branch-Konzept: Dateien erscheinen in Ihrem Arbeitsbaum, aber die Branch-Historie ändert sich erst, wenn Sie Commits auf diesem Branch erstellen.
Änderungen im Branch committen
Speichern Sie nun Ihre Arbeit. Denken Sie an den standardmäßigen Git-Ablauf: Initialisieren -> Stagen -> Committen.
Überprüfen Sie den Status:
git status
login.sh wird als Untracked angezeigt.
Stagen Sie die Datei:
git add login.sh
Committen Sie die Datei in die Historie von feature_login:
git commit -m "Add login feature script"
Ausgabe:
[feature_login 8a2b3c] Add login feature script
Sie haben diese Änderung jetzt dauerhaft aufgezeichnet, aber nur in der Zeitlinie feature_login.
Diese Isolation macht Branches so nützlich. Sie können Funktionen entwickeln, testen oder mit ihnen experimentieren, ohne den Haupt-Branch weiterzuentwickeln, bis Sie dazu bereit sind.
Die Isolation der Branches überprüfen
Jetzt kommt der entscheidende Moment. Wir behaupten, dass feature_login ein vom master getrenntes Universum ist. Beweisen Sie das, indem Sie zu master zurückwechseln.
Wechseln Sie zurück zum Branch master:
git checkout master
Ausgabe:
Switched to branch 'master'
Sehen Sie sich Ihre Dateien an:
ls
Wo ist login.sh? Die Datei ist verschwunden.
Genau das wollten wir erreichen. Die Datei login.sh existiert in der Zeitlinie master nicht. Ihr Experiment ist sicher isoliert.
Um zu bestätigen, dass die Datei nicht dauerhaft verloren ist, wechseln Sie zurück zu Ihrem Feature-Branch:
git checkout feature_login
ls
Die Datei ist wieder da. Git tauscht die Dateien in Ihrem Verzeichnis sofort aus, wenn Sie zwischen den Zeitlinien wechseln.
Zusammenfassung
In diesem Lab haben Sie die Vorteile von Branching kennengelernt:
- Sicherheit: Sie können neue Funktionen in einem separaten Branch (
feature_login) entwickeln, ohne den Hauptcode (master) zu gefährden. - Kontextwechsel: Sie haben
git checkoutverwendet, um zwischen diesen parallelen Zeitlinien zu wechseln. - Isolation: Sie haben nachgewiesen, dass in einem Branch committe Änderungen nicht in einem anderen Branch erscheinen.
So arbeiten professionelle Teams. Entwickler erstellen für jede neue Funktion und jede Fehlerbehebung eigene Branches und halten dadurch die Haupt-Codebasis sauber und stabil.
