In Teil 1 haben wir euch die Basics von Git etwas näher gebracht und im zweiten Teil dieser Reihe ging es um die grundlegenden Befehle für die tägliche Arbeit mit git. Heute stellen wir euch nun vor, wie Branching und Merging in Git funtkionieren.
Von Ästen und vom Mischen
Bisher haben wir euch im Wesentlichen beschrieben, wie ihr sinnvollerweise allein an einem Git Repository arbeiten könnt. Nun möchten wir im nächsten Schritt dazu übergehen, mit mehreren Entwicklern an einem Projekt zu arbeiten. Das ist schwierig, wenn alle die Zwischenstände ihres Codes in das zentrale Repository synchronisieren, da es immer wieder auch mal Änderungen geben kann, die sich gegenseitig ausschließen oder voneinander abhängen. Eine mögliche Lösung wäre natürlich, das Synchronisieren mit dem zentralen Repository abzustimmen, doch dann ist die schöne Sicherheit, die ein Entwickler gewinnen kann, wenn er regemäßig seine Änderungen auf den Server synchronisiert, wieder dahin. Das wäre nicht im Sinne des Erfinders, also muss eine neue Arbeitsweise her. Natürlich haben die Entwickler von Git an diesen Fall gedacht und entsprechend vorgesorgt.
Das Konzept dafür heißt Branching. Ein Branch (also der Zweig eines Baums) ist ein „Abzweig“ im Quellcode. Das heißt, ihr nehmt das Projekt wie es ist und sagt „das ist nun eine Kopie, der ich folgenden Namen gebe“. Dann arbeitet ihr in dieser benannten Kopie und könnt fröhlich Abhängigkeiten zerstören und neu aufbauen und jeden Zwischenschritt ins zentrale Repo synchronisieren, denn dort wird der „Abzweig“ auch als „Abzweig“ gespeichert. Das bedeutet, auf die Abzweige der anderen Entwickler oder den „master“ genannten „Stamm“ des „Codebaums“ hat das überhaupt keinen Einfluss. Ihr könnt also sogar nicht funktionierende Arbeitsversionen in euren Branch einchecken und synchronisieren, ohne dass es irgendeinen Einfluss hätte.
Wenn ihr nun mit der Arbeit in eurem Branch fertig seid, gilt es, diese in den master zu übernehmen. Diesen Vorgang nennt man „Merge“ und üblicherweise wird euer Branch nach dem Merge gelöscht.
Grafisch sieht das so aus:
Da es zwischen eurem Branching und dem Merge in den master passieren kann, dass andere Entwickler ihrerseits Änderungen in den master gemerged haben, kann es sein, dass sie dadurch Dateien geändert haben, an denen ihr auch gearbeitet habt.
In der Abbildung seht ihr verschiedene Branches und während der orangefarbene Branch „feat/Feature1“ entwickelt wurde, wurde der grüne Branch „feat/Feature3“ entwickelt und die Ergebnisse in den master gemerged. Das heißt dass es beim Merge von „feat/Feature1“ Konflikte ergeben können, es kann also nicht direkt gemerged werden, sondern die Konflikte müssen zunächst aufgelöst (resolved) werden. Erst dann kann „feat/Feature1“ in den master Branch übernommen werden.
Es ist best practice, dass nicht der Entwickler selbst alle seine Änderungen in den master überführt, sondern dass im Projekt zumindest ein Review der geänderten Dateien stattfindet. Das bedeutet, der „merge“ wird üblicherweise nicht vom Entwickler umgesetzt, sondern lediglich initiiert. Dieses „Anfordern“ eines Merge nennt man „pull request“, dabei wird üblicherweise ein anderer Entwickler benannt, der das Review der Änderungen durchführt.
Es ist übrigens sinnvoll, euren Branches sprechende Namen zu geben. Eingebürgert hat es sich „Feature Branches“, also Branches in denen neue Features entwickelt werden mit einem „feat/“ zu beginnen, so dass eine Art Ordnerstruktur entsteht (von vielen Clienttools wird das dann übrigens auch so angezeigt). Für reine Test- oder allgemeinere Branches ist es oft sinnvoll, ein Datum sowie ein Kürzel des Entwicklers mit in den Namen zu schreiben, so kann man das Alter direkt am Namen ablesen und auch, wen man fragen muss, ob das Kunst ist, oder weg kann.
Wie funktioniert also konkret die Arbeit mit Branches? Dafür sind gar nicht so viele Befehle nötig. Wie schon bei den Git-Grundlagen liefern wir euch hier eine Übersicht der wichtigsten Befehle. Es gibt natürlich auch hier noch viel mehr Befehle, die aber für die tägliche Arbeit mit Git hoffentlich nicht nötig sind.
- Um einen neuen Branch anzulegen und in diesen zu wechseln, verwendet ihr den „checkout“-Befehl von Git:
git checkout -b <name>
Dabei ist das die Kurzform der Verkettung der Befehle Git branch mit dem ein Branch angelegt wird und Git checkout mit dem ihr den Branch wechseln könnt.
Wichtig ist dabei zu beachten: wenn bereits ein Branch mit dem angegebenen Namen existiert, bekommt ihr eine Fehlermeldung „A branch named ‚<name>‘ already exists“, in diesem Fall müsst ihr den Branch mit checkout wechseln.
- Wenn ihr mit der Arbeit in einem Branch fertig seid, wechselt ihr zurück in den Branch von dem ihr abgezweigt wart und führt eure Arbeit zusammen durch einen Aufruf von:
git merge <name>
War’s das schon? Noch nicht ganz. Wenn ihr wissen wollt, welche Branches überhaupt existieren, dann verwendet ihr git branch -a und wenn ihr einen Branch löschen wollt, dann geht das mit git branch -d <name>.
Aber nun habt ihr die wichtigsten Infos zur Arbeit mit Branches bekommen. Und um diese Information etwas zu komprimieren, folgt hier ein Skript bei dem ein Branch angelegt wird, eine Änderung in diesem Branch vorgenommen wird und der Branch dann in den Master gemerged wird:
Die Kommandos dafür sind:
echo 'Initialize' > test.txt more .\test.txt Git init Git add . Git commit -m "first commit to master branch" Git checkout -b feat/branch echo "in feature branch" >> .\test.txt more .\test.txt Git add . Git commit -m "first commit to branch" Git checkout master more .\test.txt Git merge feat/branch more .\test.txt
Mit dem Abschluss dieser Reihe solltet ihr in Git soweit „sattelfest“ sein, dass ihr Repositories klonen oder anlegen könnt, Änderungen in eure Repositories committen und diese über push und pull mit dem origin synchronisieren könnt. Außerdem solltet ihr die Grundlagen von Branching und Merging verstanden haben.
Damit steht der Verwendung von Git nichts mehr im Wege.