Login
Newsletter
Werbung

Do, 29. Januar 2015, 15:00

Git-Tutorium – Teil 2

Branches mergen

Bis jetzt wurden einige Arbeiten am Repository durchgeführt. Dieser Abschnitt soll noch kurz zusammenfassen, was alles geschah. Zunächst wurden zwei neue Branches mit den Namen content und menu erstellt. Beide basieren auf dem Branch master. Im Anschluss wurde dann ein Commit in content und zwei Commits in menu erzeugt.

Diese Änderungen können nun zusammengeführt werden. Dafür existiert der Befehl git merge. Dieser Befehl muss dort ausgeführt werden, wohin die Änderungen aus dem anderen Branch eingefügt werden sollen. In diesem Beispiel sollen die Änderungen aus den Branches content und menu in master übernommen werden. Dazu muss man auf den Branch "master" wechseln:

$ git checkout master

Anschließend kann der erste Branch gemerged werden.

$ git merge menu
Aktualisiere 24e65af..c3cf413
Fast-forward
 index.html | 10 ++++++++++
 1 file changed, 10 insertions(+)

Nach dem Merge sind die beiden Branches menu und master identisch

Sujeevan Vijayakumaran

Nach dem Merge sind die beiden Branches menu und master identisch

Git führt an dieser Stelle einen sogenannten »fast-forward merge« durch. Dies geschieht immer genau dann, wenn seit dem Abzweigen des Branches auf dem ursprünglichen Branch keine Änderungen geschehen sind. Das ist genau bei diesem Merge der Fall. Anders sieht es hingegen aus, wenn man den Branch content nach master mergen möchte.

$ git merge content

Der Befehl öffnet den in Git konfigurierten Editor, etwa vim, mit folgendem Inhalt:

Merge branch 'content'

# Bitte geben Sie eine Commit-Beschreibung ein um zu erklären, warum dieser
# Merge erforderlich ist, insbesondere wenn es einen aktualisierten
# Upstream-Branch mit einem Thema-Branch zusammenführt.
#
# Zeilen beginnend mit '#' werden ignoriert, und eine leere Beschreibung
# bricht den Commit ab.

In der Regel belässt man den Commit-Text bei dem vorgegebenen Inhalt. Gegebenenfalls kann man allerdings, wie die Nachricht bereits aussagt, einen Grund angeben, warum der Merge nötig war. Als Ausgabe erscheint nach dem Abspeichern dann folgendes:

automatischer Merge von index.html
Merge made by the 'recursive' strategy.
 index.html | 3 +++
 1 file changed, 3 insertions(+)

Der Recursive-Merge benötigt einen Merge-Commit

Sujeevan Vijayakumaran

Der Recursive-Merge benötigt einen Merge-Commit

Im Gegensatz zum ersten Merge war hier ein »recursive merge« notwendig. Dies geschieht zwar in diesem Fall auch vollkommen automatisch, die Commit-Historie sieht allerdings anders aus. Dies hängt damit zusammen, dass durch das Mergen vom Branch menu nun Änderungen auf dem Branch master passiert sind, seitdem der Branch content abgezweigt wurde. Die beiden Branches sind dadurch divergiert. Das heißt, die beiden Commits auf dem Branch content fußen nicht direkt auf dem neuen Commit aus content, welches in master überführt worden ist.

Wenn man nun das Git Log anschaut, dann sind mittlerweile alle Commits aus allen Branches in master enthalten. Zusätzlich wurde durch den letzten Merge ein weiterer Merge-Commit hinzugefügt.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung