Eine Einführung in Git Merge and Rebase: Was sie sind und wie man sie verwendet

Als Entwickler müssen sich viele von uns zwischen Merge und Rebase entscheiden. Bei all den Referenzen, die wir aus dem Internet erhalten, glauben alle: "Verwenden Sie Rebase nicht, es könnte ernsthafte Probleme verursachen." Hier werde ich erklären, was Zusammenführen und Wiederherstellen sind, warum Sie sie verwenden sollten (und nicht) und wie dies zu tun ist.

Git Merge und Git Rebase dienen demselben Zweck. Sie dienen dazu, Änderungen aus mehreren Zweigen in einen zu integrieren. Obwohl das Endziel dasselbe ist, erreichen diese beiden Methoden es auf unterschiedliche Weise, und es ist hilfreich, den Unterschied zu kennen, wenn Sie ein besserer Softwareentwickler werden.

Diese Frage hat die Git-Community gespalten. Einige glauben, dass Sie immer neu gründen sollten, andere, dass Sie immer zusammenführen sollten. Jede Seite hat einige überzeugende Vorteile.

Git Merge

Das Zusammenführen ist eine gängige Praxis für Entwickler, die Versionskontrollsysteme verwenden. Unabhängig davon, ob Zweige zu Testzwecken, zur Behebung von Fehlern oder aus anderen Gründen erstellt werden, werden beim Zusammenführen Änderungen an einem anderen Speicherort festgeschrieben. Genauer gesagt werden beim Zusammenführen die Inhalte eines Quellzweigs in einen Zielzweig integriert. In diesem Prozess wird nur der Zielzweig geändert. Der Verlauf der Quellverzweigung bleibt unverändert.

Vorteile

  • Einfach und vertraut
  • Bewahrt die vollständige Geschichte und chronologische Reihenfolge
  • Behält den Kontext des Zweigs bei

Nachteile

  • Der Commit-Verlauf kann durch viele Merge-Commits verschmutzt werden
  • Das Debuggen mit git bisectkann schwieriger werden

Wie es geht

Führen Sie den Hauptzweig mit den Befehlen checkoutund in den Feature-Zweig ein merge.

$ git checkout feature $ git merge master (or) $ git merge master feature

Dadurch wird im Feature-Zweig ein neues " Merge Commit " erstellt, das den Verlauf beider Zweige enthält.

Git Rebase

Rebase ist eine weitere Möglichkeit, Änderungen von einem Zweig in einen anderen zu integrieren. Rebase komprimiert alle Änderungen in einem einzigen "Patch". Anschließend wird der Patch in den Zielzweig integriert.

Im Gegensatz zum Zusammenführen wird durch das erneute Basieren der Verlauf abgeflacht, da die abgeschlossene Arbeit von einem Zweig in einen anderen übertragen wird. Dabei wird unerwünschte Historie beseitigt.

Bei Rebases sollten Änderungen von der Spitze der Hierarchie nach unten und bei Zusammenführungen nach oben zurückgeführt werden

Vorteile

  • Optimiert eine möglicherweise komplexe Geschichte
  • Das Manipulieren eines einzelnen Commits ist einfach (z. B. Zurücksetzen)
  • Vermeidet das Zusammenführen von Commit-Rauschen in ausgelasteten Repos mit ausgelasteten Zweigen
  • Bereinigt Zwischen-Commits, indem sie zu einem einzigen Commit gemacht werden, was für DevOps-Teams hilfreich sein kann

Nachteile

  • Wenn Sie die Funktion auf eine Handvoll Commits reduzieren, kann der Kontext ausgeblendet werden
  • Das Wiederherstellen öffentlicher Repositorys kann gefährlich sein, wenn Sie als Team arbeiten
  • Es ist mehr Arbeit: Verwenden Sie rebase, um Ihren Feature-Zweig immer auf dem neuesten Stand zu halten
  • Für die Wiederherstellung mit Remote-Zweigen müssen Sie einen Push erzwingen. Das größte Problem, mit dem Menschen konfrontiert sind, ist, dass sie Push erzwingen, aber nicht die Standardeinstellung für Git Push festgelegt haben. Dies führt zu Aktualisierungen aller Zweige mit demselben Namen, sowohl lokal als auch remote, und es ist schrecklich , damit umzugehen.
Wenn Sie den Verlauf falsch und unbeabsichtigt neu schreiben, kann dies zu schwerwiegenden Problemen führen. Stellen Sie also sicher, dass Sie wissen, was Sie tun!

Wie es geht

Stellen Sie den Feature-Zweig mit den folgenden Befehlen auf den Hauptzweig um.

$ git checkout feature $ git rebase master

Dadurch wird der gesamte Feature-Zweig über den Master-Zweig verschoben. Dazu wird die Projekthistorie neu geschrieben, indem für jedes Commit im ursprünglichen (Feature-) Zweig brandneue Commits erstellt werden.

Interaktives Wiederherstellen

Auf diese Weise können Sie die Commits ändern, wenn sie in den neuen Zweig verschoben werden. Dies ist leistungsfähiger als die automatische Neubasis, da es die vollständige Kontrolle über den Festschreibungsverlauf des Zweigs bietet. In der Regel wird dies verwendet, um einen unordentlichen Verlauf zu bereinigen, bevor ein Feature-Zweig mit dem Master zusammengeführt wird.

$ git checkout feature $ git rebase -i master

Dadurch wird der Editor geöffnet, indem alle Commits aufgelistet werden, die verschoben werden sollen.

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Dies definiert genau, wie der Zweig aussehen wird, nachdem die Rebase durchgeführt wurde. Durch Neuanordnen der Entitäten können Sie den Verlauf so gestalten, wie Sie es möchten. Zum Beispiel können Sie Befehle wie verwenden fixup, squash, editusw., anstelle von pick.

Welches zu verwenden

Was ist das Beste? Was empfehlen die Experten?

Es ist schwer zu verallgemeinern und sich für das eine oder andere zu entscheiden, da jedes Team anders ist. Aber wir müssen irgendwo anfangen.

Teams müssen beim Festlegen ihrer Git-Rebase- oder Merge-Richtlinien mehrere Fragen berücksichtigen. Denn wie sich herausstellt, ist eine Workflow-Strategie nicht besser als die andere. Es hängt von Ihrem Team ab.

Berücksichtigen Sie den Grad der Neugründung und die Git-Kompetenz in Ihrem Unternehmen. Bestimmen Sie, inwieweit Sie die Einfachheit der Neubasierung im Vergleich zur Rückverfolgbarkeit und dem Verlauf der Zusammenführung schätzen.

Schließlich sollten Entscheidungen über das Zusammenführen und erneute Basieren im Kontext einer klaren Verzweigungsstrategie betrachtet werden ( Weitere Informationen zur Verzweigungsstrategie finden Sie in diesem Artikel ). Eine erfolgreiche Verzweigungsstrategie basiert auf der Organisation Ihrer Teams.

Was empfehle ich?

Wenn das Team wächst, wird es schwierig, Entwicklungsänderungen mit einer immer zusammengeführten Richtlinie zu verwalten oder zu verfolgen . Um einen sauberen und verständlichen Commit-Verlauf zu haben, ist die Verwendung von Rebase sinnvoll und effektiv.

Wenn Sie die folgenden Umstände und Richtlinien berücksichtigen, können Sie Rebase optimal nutzen:

  • Sie entwickeln sich lokal: Wenn Sie Ihre Arbeit nicht mit anderen geteilt haben. An diesem Punkt sollten Sie es vorziehen, neu zu gründen, anstatt zusammenzuführen, um Ihren Verlauf sauber zu halten. Wenn Sie Ihren persönlichen Zweig des Repositorys haben und dieser nicht mit anderen Entwicklern geteilt wird, können Sie ihn auch nach dem Push in Ihre Filiale sicher neu starten.
  • Ihr Code kann überprüft werden: Sie haben eine Pull-Anforderung erstellt. Andere überprüfen Ihre Arbeit und holen sie möglicherweise zur lokalen Überprüfung in ihre Gabel. Zu diesem Zeitpunkt sollten Sie Ihre Arbeit nicht neu begründen. Sie sollten Nacharbeits-Commits erstellen und Ihren Feature-Zweig aktualisieren. Dies hilft bei der Rückverfolgbarkeit in der Pull-Anforderung und verhindert den versehentlichen Bruch der Historie.
  • Die Überprüfung ist abgeschlossen und kann in den Zielzweig integriert werden. Herzliche Glückwünsche! Sie sind dabei, Ihren Feature-Zweig zu löschen. Angesichts der Tatsache, dass andere Entwickler diese Änderungen ab diesem Zeitpunkt nicht mehr zusammenführen, ist dies Ihre Chance, Ihren Verlauf zu bereinigen. An diesem Punkt können Sie den Verlauf neu schreiben und die ursprünglichen Commits und diese lästigen "Pr Rework" - und "Merge" -Commits zu einem kleinen Satz fokussierter Commits zusammenfassen. Das Erstellen einer expliziten Zusammenführung für diese Commits ist optional, hat jedoch einen Wert. Es wird aufgezeichnet, wann die Funktion zum Master abgeschlossen wurde.

Fazit

Ich hoffe, diese Erklärung hat einige Einblicke in Git Merge und Git Rebase gegeben. Die Strategie von Merge vs Rebase ist immer umstritten. Aber vielleicht hilft dieser Artikel dabei, Ihre Zweifel zu zerstreuen und einen Ansatz zu wählen, der für Ihr Team funktioniert.

Ich freue mich darauf, über Git-Workflows und Konzepte von Git zu schreiben . Kommentieren Sie die Themen, über die ich als nächstes schreiben soll. Prost!

code = coffee + developer

Codierschule für Softwareentwickler