Unterschied zwischen Git ReBase und Merge
In diesem Artikel werden zwei solcher Tools, Rebase und Merge, sowie deren Unterschiede behandelt. GIT ist einer der am häufigsten verwendeten verteilten DVCS-Versionscontroller unter den Programmierern, da es dynamisch ist und über umfangreiche Tools für die Bearbeitung der Versionen verfügt. Es gibt zwei Möglichkeiten, wie wir unsere Änderungen von einem Zweig zu einem anderen senden können. Zum einen durch Rebase und zum anderen durch Merge, was sehr beliebt ist. Nachfolgend lernen wir den Top-Vergleich zwischen Git ReBase vs Merge.
Head to Head Vergleich zwischen Git ReBase und Merge (Infografik)
Nachfolgend sind die fünf besten Vergleiche zwischen Git ReBase und Merge aufgeführt:
Hauptunterschiede zwischen Git ReBase und Merge
Lassen Sie uns den Hauptunterschied zwischen Git ReBase und Merge diskutieren:
1. Git Rebase
Git Rebase beginnt seine Arbeit mit einem gemeinsamen Commit zwischen den beiden Zweigen. Master und Feature, von hier aus werden beide verglichen und der Schnappschuss des Unterschieds, der in einem der Zweige gemacht wird, erfasst und dann zu anderen hinzugefügt. Schauen wir uns das mit den folgenden Screenshots an.
Stellen wir uns vor, wir haben einen Master-Zweig und verpflichten uns dazu, m2, wie im obigen Screenshot gezeigt. Aus diesem Commit erstellen wir einen Feature-Zweig und haben einige Änderungen vorgenommen und das Commit mit der Nachricht f1 ausgeführt. Nehmen wir nun an, jemand hat seine Arbeit zum Master zusammengeführt, und jetzt ist das letzte Commit des Masters m3, nicht m2, wie unten gezeigt.
Wir arbeiten auch weiterhin an der Feature-Verzweigung, um das neueste Commit für f2 hinzuzufügen, wie unten gezeigt.
Wie oben auf dem Screenshot zu sehen, haben wir das neueste Commit m3 gemastert, und wir haben eine Funktion, die mit dem Master nicht auf dem neuesten Stand ist, da er aus dem m2-Commit-Snapshot mit dem neuesten Commit f3 erstellt wurde. Nachfolgend wird gezeigt, wie Sie diese Bemühungen mit dem zu generierenden Master kombinieren können.
Jetzt müssen wir die obigen Änderungen integrieren, die auf zwei Arten vorgenommen werden können: mit Merge und mit Rebase. Hier sehen wir uns an, wie man Rebase integriert.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Mit dem obigen Befehl rebase versuchen wir, nach einem gemeinsamen Commit von master und feature zu suchen. In diesem Fall ist es m2. Und da wir dann den Master rebasieren müssen, wird nach Ergänzungen gesucht, die mit dem Master durchgeführt wurden, und es werden Momentaufnahmen von m3 und die Rebase-Funktion von m2 auf m3 erstellt. Also haben wir jetzt ein Feature mit m3 (anstelle von m2), f1, f2 festgeschrieben. Jetzt kann ich beantragen, das Feature zu rebasieren, um den Master-Zweig mit den Feature-Änderungen zu aktualisieren. Eine Sache, an die Sie sich erinnern sollten, ist, dass jede Änderung am Master überprüft werden muss. Hier zeige ich nur zum Beispiel Zweck.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
In diesem Abschnitt wenden wir den neuesten Zweig der Festschreibungsfunktion, f2, auf den Master an, und der letzte Festschreibungsschnappschuss des Masters ist f2. Sie können die Commits mit dem Befehl git log auflisten, aber wir müssen zuerst überprüfen, in welchem Zweig wir das Protokoll wie unten sehen müssen.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Jetzt haben wir mit rebase die Updates eines zu meisternden Features integriert. Versuchen wir, dies durch Zusammenführung zu erreichen.
2. Git Merge
Wir werden den obigen Screenshot auch als Referenz verwenden, und wir können dasselbe erreichen, was wir mit Rebase und Merge erreicht haben.
Git merge schreibt das letzte Commit fest, das wir im Feature-Zweig hatten, und in diesem Fall mit f2 commit, das alle Änderungen sammelt und es mit dem letzten Commit zusammenführt, das wir im Master-Zweig haben, m3 hier. Dies sieht kompliziert aus, kann aber einfach mit dem Befehl merge ausgeführt werden. Wir können entweder eine direkte Verschmelzung oder eine Squash-Verschmelzung durchführen und den Unterschied zwischen beiden feststellen.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Der obige Befehl übernimmt alle Commits der Funktion und fügt sie auch in das Protokoll des Masters ein. Um zu vermeiden, dass wir Squash verwenden können, werden wir im Log des Masters nach m3 nur ein Commit durchführen und das ist ein Update
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
Bei der Verwendung von Git Rebase sollte man vorsichtig sein und versuchen, dies zu vermeiden. Die goldene Regel ist, es zu vermeiden, öffentliche Zweige zu verwenden.
Schauen Sie sich einfach das obige Szenario an. Dies kann passieren, wenn Sie versuchen, den Master über Ihrem Feature-Zweig wiederherzustellen und unser Master-Zweig öffentlich ist. Jetzt wird der Master-Zweig aktualisiert, aber alle anderen arbeiten an einer älteren Version von Master. Da das Umbasieren zu brandneuen Commits führen wird, kann git glauben, dass die Geschichte der Master-Branche von allen anderen abgewichen ist. Die einzige Möglichkeit, dies zu lösen, besteht darin, beide Master zu synchronisieren, indem sie wieder zusammengeführt werden. Dies führt zu einer Reihe verwirrender Festschreibungen.
Vergleichstabelle von Git ReBase vs Merge
Die folgende Tabelle fasst die Vergleiche zwischen Git ReBase und Merge zusammen:
| Vergleichsbasis zwischen Rebase und Merge | Rebase | Verschmelzen |
| Commits | Der Verlauf wird geändert und neu geschrieben, indem für jedes Commit im Quellzweig ein neues Commit erstellt wird. | Es enthält alle Änderungen an der Quelle, behält jedoch die Vorfahren der einzelnen Festschreibungsprotokolle bei. Es enthält alle Änderungen an der Quelle, behält jedoch die Vorfahren der einzelnen Festschreibungsprotokolle bei. |
| Auswahl | Hier checken wir zuerst den Zweig aus, der rebasiert werden muss, und wählen dann den Befehl rebase aus um es anderen zu aktualisieren. | Hier zuerst den Zweig auschecken, der zuerst zusammengeführt werden muss. Führen Sie dann den Zusammenführungsvorgang und das letzte Festschreiben der Quelle durch wird mit dem letzten Commit des Masters zusammengeführt. |
| Konfliktbearbeitung | Da die Festschreibungshistorie umgeschrieben wird, um zu verstehen, wird der Konflikt in schwierig sein manche Fälle. | Zusammenführungskonflikte können leicht behandelt werden, indem Sie den Fehler verstehen, der beim Zusammenführen aufgetreten ist. |
| goldene Regel | Sollte auf den öffentlichen Zweigen verwendet werden, da der Commit-Verlauf Verwirrung stiften kann. | Kein großer Schaden bei der Ausführung von öffentlichen Filialen. |
| Erreichbarkeit | Einmal erreichbare Commits sind nach dem Rebase nicht mehr erreichbar, da der Commit-Verlauf geändert wird. | Commits bleiben erreichbar aus den Quellzweigen. |
Fazit
Merge und Rebase sind zwei leistungsstarke Tools von Git, die beide verwendet werden, um die Änderungen an den Zweigen zu übernehmen. Wir müssen jedoch ein wenig vorsichtig mit Rebase sein, da sie den Verlauf von Commits neu schreiben und die Verwendung in öffentlichen Zweigen die Arbeit behindern kann von anderen, die sie verwirren. Während Sie die Zusammenführungsoption verwenden können, da die Commits vom Quellzweig aus erreichbar sind und Zusammenführungskonflikte leicht gelöst werden können, wenn wir das richtige Verständnis haben.
Empfohlene Artikel
Dies ist eine Anleitung zum Hauptunterschied zwischen Git ReBase und Merge. Hier diskutieren wir auch die wichtigsten Unterschiede zwischen Git ReBase und Merge mit Infografiken und Vergleichstabelle. Sie können sich auch die folgenden Artikel ansehen, um mehr zu erfahren -
- Git Fetch vs Git Pull - Top Unterschiede
- Abstraktion gegen Verkapselung Top 6 Vergleich
- HBase-Architektur mit Vorteilen
- Im Vorstellungsgespräch bei GIT | Top 11
- GIT Versionskontrollsystem
- Git Push
- Kapselung in JavaScript
- Komplette Anleitung zu Git Remote Command
- Drei Stufen des Git-Lebenszyklus mit dem Workflow
- Wie benutzt man GIT Cherry-pick mit Example?