von Valium

Als Entwickler müssen viele von uns zwischen Merge und Rebase wählen. Mit all den Referenzen, die wir aus dem Internet erhalten, glaubt jeder: „Verwenden Sie Rebase nicht, es könnte ernsthafte Probleme verursachen.“Hier werde ich erklären, was Merge und Rebase sind, warum Sie sie verwenden sollten (und sollten) und wie dies zu tun ist.

Git Merge und Git Rebase dem gleichen Zweck dienen. Sie wurden entwickelt, um Änderungen aus mehreren Zweigen in einen zu integrieren., Obwohl das Endziel das gleiche 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, Sie sollten immer Rebase und andere, die 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 zum Testen, für Fehlerbehebungen oder aus anderen Gründen erstellt werden, verpflichtet sich das Zusammenführen von Änderungen an einem anderen Speicherort., Um genauer zu sein, nimmt Merging den Inhalt eines Quellzweigs und integriert ihn in einen Zielzweig. In diesem Prozess wird nur der Zielzweig geändert. Der Verlauf des Quellenzweigs bleibt gleich.,da2a4595a“>

Merge Master -> Feature branch

Pros

  • Simple and familiar
  • Bewahrt die vollständige Historie und chronologische Reihenfolge
  • Behält den Kontext der Verzweigung

Cons

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

Wie es geht

Führen Sie den Master-Zweig mit den Befehlen checkout und merge in den Feature-Zweig ein.,

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

Dadurch wird ein neues“ Merge Commit “ im Feature-Zweig 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.“Dann integriert es den Patch in den Zielzweig.

Im Gegensatz zum Zusammenführen glättet das Rebasing den Verlauf, da die abgeschlossene Arbeit von einem Zweig auf einen anderen übertragen wird. Dabei wird unerwünschter Verlauf eliminiert.,

Rebases sind, wie Änderungen von der Spitze der Hierarchie nach unten passieren sollten, und Merges sind, wie sie nach oben fließen zurück

Rebase Feature Zweig in master

  • Rationalisiert einen potenziell komplexen Verlauf
  • Die Manipulation eines einzelnen Commits ist einfach (z.,
  • Vermeidet Merge-Commits in ausgelasteten Repos mit ausgelasteten Zweigen
  • Bereinigt Zwischen-Commits, indem Sie sie zu einem einzigen Commit machen, was für DevOps-Teams hilfreich sein kann

Cons

  • Das Zerquetschen der Funktion auf eine Handvoll Commits kann den Kontext verbergen
  • Das Rebasing öffentlicher Repositorys kann gefährlich sein, wenn Sie als Team arbeiten
  • Es ist mehr Arbeit: rebase Um Ihren Feature-Zweig immer auf dem neuesten Stand zu halten
  • Rebasing mit Remote-Zweigen erfordert, dass Sie Push erzwingen., Das größte Problem, mit dem die Leute konfrontiert sind, ist, dass sie Push erzwingen, aber keinen Git Push-Standard festgelegt haben. Dies führt zu Updates für alle Zweige mit dem gleichen Namen, sowohl lokal als auch remote, und das ist schrecklich zu behandeln.

Wenn Sie falsch rebase und unbeabsichtigt die Geschichte neu zu schreiben, kann es zu ernsthaften Problemen führen, so stellen Sie sicher, dass Sie wissen, was Sie tun!

Wie es geht

Rebase die feature zweig auf die master zweig mit den folgenden befehlen.,

$ git checkout feature$ git rebase master

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

Interaktives Rebasing

Dadurch können die Commits geändert werden, wenn sie in den neuen Zweig verschoben werden. Dies ist leistungsfähiger als die automatisierte Rebase, da sie die vollständige Kontrolle über den Commit-Verlauf des Zweigs bietet. In der Regel wird dies verwendet, um einen unordentlichen Verlauf zu bereinigen, bevor ein Feature-Zweig in 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#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

Dies definiert genau, wie der Zweig nach der Rebase aussehen wird. Indem Sie die Entitäten neu anordnen, können Sie den Verlauf so aussehen lassen, wie Sie möchten. Sie können beispielsweise Befehle wie fixup, squash, edit usw. anstelle von .

Die man zu verwenden

Also, was ist am besten?, Was empfehlen die Experten?

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

Teams müssen beim Festlegen ihrer Git Rebase vs. Merge-Richtlinien mehrere Fragen berücksichtigen. Denn wie sich herausstellt, ist eine Workflow-Strategie nicht besser als die andere. Es ist abhängig von Ihrem team.

Berücksichtigen Sie die Rebasing-und Git-Kompetenz in Ihrem Unternehmen. Bestimmen Sie, inwieweit Sie die Einfachheit des Rebasings im Vergleich zur Rückverfolgbarkeit und Historie des Zusammenführens schätzen.,

Schließlich sollten Entscheidungen über das Zusammenführen und Rebasing im Rahmen einer klaren Verzweigungsstrategie berücksichtigt werden (Siehe diesen Artikel, um mehr über die Verzweigungsstrategie zu erfahren). Eine erfolgreiche Verzweigungsstrategie basiert auf der Organisation Ihrer Teams.

Was empfehle ich?

Wenn das Team wächst, wird es schwierig, Entwicklungsänderungen mit einer Always Merge-Richtlinie zu verwalten oder zu verfolgen. Um einen sauberen und verständlichen Commit-Verlauf zu erhalten, 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 lokal: Wenn Sie Ihre Arbeit nicht mit anderen geteilt haben. Zu diesem Zeitpunkt sollten Sie das Rebasing dem Merging vorziehen, um Ihre Historie aufgeräumt zu halten. Wenn Sie Ihren persönlichen Fork des Repositorys haben und dieser nicht mit anderen Entwicklern geteilt wird, können Sie ihn auch nach dem Pushen in Ihren Zweig erneut erstellen.
  • Ihr Code ist zur Überprüfung bereit: Sie haben eine Pull-Anforderung erstellt. Andere überprüfen Ihre Arbeit und holen sie möglicherweise zur lokalen Überprüfung in ihre Gabel., An diesem Punkt sollten Sie Ihre Arbeit nicht Rebase. Sie sollten „Rework“ – Commits erstellen und Ihren Feature-Zweig aktualisieren. Dies hilft bei der Rückverfolgbarkeit in der Pull-Anforderung und verhindert den versehentlichen Verlaufsbruch.
  • Die Überprüfung ist abgeschlossen und kann in den Zielzweig integriert werden. Herzlichen Glückwunsch! Sie sind dabei, Ihren Feature-Zweig zu löschen. Da andere Entwickler diese Änderungen ab diesem Zeitpunkt nicht mehr abrufen, ist dies Ihre Chance, Ihren Verlauf zu bereinigen., An diesem Punkt können Sie den Verlauf umschreiben und die ursprünglichen Commits und diese lästigen ‚pr Rework‘ – und ‚Merge‘ – Commits in einen kleinen Satz fokussierter Commits falten. Das Erstellen einer expliziten Zusammenführung für diese Commits ist optional, hat jedoch einen Wert. Es zeichnet auf, wann die Funktion zum Master wechselt.

Fazit

Ich hoffe, diese Erklärung hat einige Einblicke in Git merge und Git rebase gegeben. Merge vs. rebase-Strategie ist immer fraglich. Aber vielleicht hilft dieser Artikel, Ihre Zweifel zu zerstreuen und Ihnen einen Ansatz zu ermöglichen, der für Ihr Team funktioniert.