Git Tutorial - Merge

Jinku Hu 30 Januar 2023
  1. Schneller Vorlauf git merge
  2. Rekursives git merge
  3. Konflikte auflösen
Git Tutorial - Merge

Wir werden in diesem Tutorial lernen, wie man Zweige zusammenführt und auch Konflikte behandeln, wenn es sie gibt.

Im letzten Tutorial haben wir einen neuen Zweig erstellt, um an einigen neuen Funktionen zu arbeiten, die wir nicht den master-Zweig durcheinander bringen wollen.

Nachdem wir diese neuen Zweige erstellt haben und mit den neuen Funktionen zufrieden sind, müssen wir sie wieder in den master-Zweig einführen. So dass, wenn wir den nächsten Release-Code veröffentlichen, die neue Funktion ebenfalls enthalten ist.

Schneller Vorlauf git merge

Sagen wir, wir sind glücklich mit den Änderungen im new_test_branch Zweig und wir werden ihn wieder mit dem master zusammenführen.

  • Check out master Branch
   $ git checkout master
  • Den Zweig mit dem master verschmelzen
   $ git merge new_test_branch
   Updating 5fef94e..e7a7e81
	Fast-forward
	test3.txt | 3 ++-
	1 file changed, 2 insertions(+), 1 deletion(-)

Wir haben das Feature aus dem Zweig new_test_branch genommen und in diesen master Zweig eingegliedert.

Der Fast-forward, der in der Nachricht nach dem Einmischen angezeigt wird, bedeutet, dass git einen Schnellvorlauf bis zu den Code-Änderungen durchführt, die wir im Zweig gemacht haben, weil wir in der Zeit zwischen dem Verzweigen und dem Zurückmischen in den Master-Zweig eigentlich keine Änderungen im master-Zweig gemacht haben.

Rekursives git merge

Bevor wir diesen unterschiedlichen git merge demonstrieren, müssen wir zwei Zweige test_branch_A und test_branch_B erstellen und verschiedene Änderungen an ihnen vornehmen. Dann werden wir den test_branch_A zurück zum master Zweig verschmelzen.

Jetzt werden wir den test_branch_B mit dem master zusammenführen.

$ git merge test_branch_B
Merge made by the 'recursive' strategy.
 test1_rename.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Der Unterschied zwischen diesem Merge und dem Fast-Forward Merge ist, dass der Merge durch die rekursive Strategie gemacht wird, weil dieser Zweigcode nicht die Funktion test_branch_A in sich hat. Mit anderen Worten, der master-Zweig hat sich geändert, nachdem der Zweig test_branch_B erzeugt wurde.

Nun ist master mit diesen beiden Features auf dem neuesten Stand, und es spielt keine Rolle, dass wir an ihnen zur gleichen Zeit gearbeitet haben, verschiedene Leute, die sie mit beiden machen, führen sie einfach wieder zusammen und alles ist in Ordnung.

Konflikte auflösen

Was wir in zwei Testzweigen modifiziert haben, hat keinen Konflikt, aber was ist, wenn es Konflikte gibt, wenn Sie einige Zweige mit dem master zusammenführen?

Lassen Sie uns zwei Zweige test_branch_C und test_branch_D erstellen, dann fügen wir den Text Der Buchstabe sollte C an die Datei test3.txt im Zweig test_branch_C und den Text The letter should be D an die Datei test3.txt im Zweig test_branch_D anhängen.

Dann fügen wir den test_branch_C wieder in den master Zweig ein.

Nun werden wir test_branch_D in den master einmischen,

$ git merge test_branch_D
Auto-merging test3.txt
CONFLICT (content): Merge conflict in test3.txt
Automatic merge failed; fix conflicts and then commit the result.

Sie konnten hier sehen, dass es nicht erfolgreich zusammengeführt werden konnte, weil es den Konflikt in der Datei test3.txt erkennt. Wir müssen den Konflikt manuell auflösen, indem wir die konfligierende Datei bearbeiten.

Die Datei test3.txt zeigt den Konflikt als

<<<<<<< HEAD
The letter should be C
=======
The letter should be D
>>>>>>> test_branch_D

Der Text zwischen HEAD und ========== ist der Text im master Zweig, der aus dem zusammengelegten Zweig test_branch_C stammt, der sich von dem Text im zu verbindenden Zweig test_branch_D unterscheidet.

Sie müssen wählen, welcher Text im master behalten werden soll, und alle Symbole wie <<<<<< und >>>>> löschen.

Sagen wir, der angehängte Text soll The letter should be D sein. Wir aktualisieren den Konfliktbereich auf The letter should be D sein.

Nachdem wir den Konflikt gelöst haben, können wir den gelösten Konflikt mit git commit übergeben.

Autor: Jinku Hu
Jinku Hu avatar Jinku Hu avatar

Founder of DelftStack.com. Jinku has worked in the robotics and automotive industries for over 8 years. He sharpened his coding skills when he needed to do the automatic testing, data collection from remote servers and report creation from the endurance test. He is from an electrical/electronics engineering background but has expanded his interest to embedded electronics, embedded programming and front-/back-end programming.

LinkedIn Facebook