Einführung
Dieser Artikel ist der dritte Teil der Reihe «Git verwenden». Er setzt voraus, dass Sie sowohl den Installationsartikel als auch den Artikel „Effektive Nutzung von Git“ gelesen haben.
Im Bereich der Versionskontrollsysteme zählt Git zweifellos zu den flexibelsten. Die Syntax ist sehr leicht zu erlernen, und es ist einfach zu verstehen, wie Git Ihren Workflow und Ihre Umgebung optimal unterstützen kann.
Dieses Tutorial zeigt Ihnen, wie Sie zwei Branches (master und development) erstellen und wie Sie Code von der Entwicklungs- in die Produktionsversion zusammenführen.
Ein Branch ist im Kern eine eindeutige Folge von Codeänderungen mit einem eindeutigen Namen. Jedes Repository kann einen oder mehrere Branches haben.
Standardmäßig heißt der erste Branch “master”.
Filialen ansehen
Bevor wir neue Branches erstellen, möchten wir alle vorhandenen Branches sehen. Wir können alle vorhandenen Branches anzeigen, indem wir Folgendes eingeben:
git branch -a
Durch Hinzufügen von “-a” am Ende des Befehls wird GIT mitgeteilt, dass alle verfügbaren Branches angezeigt werden sollen, einschließlich derer, die sich nicht in unserem lokalen Arbeitsbereich befinden.
Das Ergebnis wird in etwa wie folgt aussehen:
* master remotes/origin/master
Das Sternchen neben “master” in der ersten Zeile der Ausgabe zeigt an, dass wir uns aktuell auf diesem Branch befinden. Die zweite Zeile zeigt lediglich an, dass es auf unserem Remote-Server nur einen einzigen Branch gibt, der „origin“ heißt und ebenfalls „master“ genannt wird.
Nachdem wir nun wissen, wie man Branches anzeigt, ist es an der Zeit, unseren ersten Branch zu erstellen.
Zweige erstellen
Wie bereits am Anfang dieses Artikels erwähnt, möchten wir eine Entwicklungs- und eine Produktionsumgebung für unsere Codierungsumgebung einrichten.
Wir möchten den Standard-«Master»-Branch als unseren Produktions-Branch verwenden und müssen daher einen separaten Branch für die Entwicklung bzw. Vorproduktion erstellen.
Um einen neuen Branch namens „develop“ zu erstellen, geben Sie Folgendes ein:
git checkout -b develop
Angenommen, wir haben noch keinen Zweig namens “Entwicklung”, dann sieht die Ausgabe wie folgt aus:
Switched to a new branch 'develop'
Falls bereits ein Branch mit diesem Namen existiert, teilt uns GIT Folgendes mit:
fatal: A branch named 'develop' already exists.
Sie können mit dem Befehl `git checkout` zwischen Ihren beiden Branches hin- und herwechseln:
git checkout master
Oder
git checkout develop
Angenommen, es gibt einen Zweig, zu dem Sie wechseln möchten, sehen Sie eine Ausgabe, die in etwa wie folgt aussieht:
Switched to branch 'master'
Wenn Sie versuchen, zu einem nicht existierenden Zweig zu wechseln, wie zum Beispiel
git checkout nosuchbranch
Git sagt Ihnen:
error: pathspec 'nosuchbranch' did not match any file(s) known to git.
Da wir nun mehrere Branches haben, müssen wir diese sinnvoll nutzen. In unserem Fall verwenden wir den “Entwicklungs”-Branch zum Testen unserer Änderungen und den Master-Branch, um sie zu veröffentlichen.
Um diesen Prozess zu veranschaulichen, müssen wir zu unserem Entwicklungszweig zurückkehren:
git checkout develop
Änderungen an unserer Entwicklungsabteilung vornehmen
In diesem Branch erstellen wir eine neue, leere Datei namens “develop”. Diese wird erst existieren, wenn wir sie (im nächsten Schritt) in den Haupt-Branch zusammenführen.
touch develop
Genau wie im vorherigen Tutorial müssen wir Git mitteilen, dass wir diese neue Datei verfolgen möchten.
Wir können die “develop”-Datei hinzufügen, indem wir Folgendes eingeben:
git add develop
Die oben genannten Befehle erstellen eine leere Datei namens “develop” und fügen sie zu GIT hinzu.
Wir müssen diese Datei auch einchecken, wodurch sie dem Branch “development” hinzugefügt wird, in dem wir uns aktuell befinden.
git commit -m "develop file" develop
Diese Datei existiert nun im Entwicklungszweig. Wie wir gleich feststellen werden, existiert sie nicht im Master-Zweig.
Zunächst möchten wir sicherstellen, dass wir uns im Entwicklungszweig befinden. Dies können wir durch Eingabe folgender Befehle tun:
git branch
Das Ergebnis sollte in etwa der folgenden Abbildung ähneln:
* develop master
Wir haben bereits verstanden, dass der Stern neben dem Zweignamen anzeigt, dass wir uns aktuell auf diesem Zweig befinden.
Die Ausführung des Befehls “ls” zeigt uns, dass diese beiden Dateien existieren:
lsDie Ausgabe zeigt uns, dass unsere beiden Dateien unter den Namen “file” bzw. “develop” gefunden wurden:
develop file
Code zwischen Zweigen zusammenführen
Der interessante Teil beginnt, nachdem wir zu unserem ursprünglichen Branch zurückwechseln, was wir mit dem Befehl `git checkout` tun können:
git checkout master
Um sicherzustellen, dass wir uns im Hauptzweig befinden, können wir Folgendes eingeben:
git branch
Die Ausgabe zeigt uns, auf welchem Zweig wir uns befinden, gekennzeichnet durch das Sternchen.
develop * master
Beim erneuten Ausführen von “ls” scheint unsere neue Datei zu fehlen.
fileEs ist nicht verloren – es befindet sich in unserem Entwicklungszweig und wir sind in unserem Hauptzweig.
In unserem Szenario repräsentiert diese Datei alle Änderungen an beliebigen Dateien (oder eine komplett neue Datei), die alle Tests in unserem Entwicklungszweig bestanden hat und für die Produktion bereit ist. Der Vorgang des Verschiebens von Code zwischen Zweigen (häufig von der Entwicklung zur Produktion) wird als Merge bezeichnet.
Beim Zusammenführen ist es wichtig, daran zu denken, dass wir uns auf dem Branch befinden müssen, in den wir zusammenführen möchten.
In diesem Fall möchten wir von unserem Entwicklungszweig, in dem die Datei “develop” existiert, in unseren Master-Zweig mergen.
Vor diesem Hintergrund und da wir uns aktuell auf dem Master-Branch befinden, müssen wir lediglich den Merge-Befehl ausführen.
Eine der Optionen, die wir dem Merge-Befehl übergeben können, “--no-ff”, bedeutet, dass Git alle Commit-Nachrichten vor dem Merge beibehalten soll. Dies erleichtert das Nachverfolgen von Änderungen in der Zukunft.
Um Änderungen vom Entwicklungszweig in den Masterzweig zu übernehmen, geben Sie Folgendes ein:
git merge develop --no-ff
Die Ausgabe des Befehls sieht in etwa wie folgt aus:
Merge made by the 'recursive' strategy. 0 files changed create mode 100644 develop
Ein erneuter Aufruf des Befehls ls bestätigt, dass sich unsere “develop”-Datei nun im Hauptzweig befindet.
develop file
Als Letztes müssen wir nun die Änderungen auf den Remote-Server übertragen, was wir mit Hilfe des Befehls git push tun können.
git push
Sie sehen eine Ausgabe ähnlich der folgenden, die bestätigt, dass Sie die Änderungen von Ihrem Entwicklungszweig in den Master-Zweig auf Ihrem Remote-Server zusammengeführt haben:
Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 332 bytes, done. Total 3 (delta 1), reused 0 (delta 0) To ssh://[email protected]/repository 9af2dcb..53649cf master -> master
Ergebnis
Nachdem Sie dem obigen Tutorial gefolgt sind, sollten Sie einen Workflow mit zwei Branches eingerichtet haben und hoffentlich ein gutes Verständnis dafür entwickelt haben, wie Branching in Git funktioniert. Teilen Sie uns Ihre Meinung in den Kommentaren mit!
