Entwickler haben häufig die Wahl zwischen Zusammenführen (Zusammenführen) und Wiederherstellen (Verschieben). In Google werden Sie eine andere Meinung sehen, vielen wird empfohlen, Rebase nicht zu verwenden, da dies schwerwiegende Probleme verursachen kann. In dem Artikel werde ich erklären, was Zusammenführen und Verschieben sind, warum Sie sie verwenden sollten (oder nicht) und wie es geht.

Git Merge und Git Rebase haben dasselbe Ziel. Sie dienen dazu, Änderungen von einem Zweig in einen anderen zu integrieren. Obwohl das Endziel dasselbe ist, unterscheiden sich die Funktionsprinzipien.
Einige Leute denken, Sie sollten Rebase immer verwenden, andere bevorzugen Merge. Das hat Vor- und Nachteile.
Git zusammenführen
Das Zusammenführen ist eine gängige Praxis für Entwickler, die Versionskontrollsysteme verwenden. Unabhängig davon, ob Zweige zum Testen, zur Fehlerbehebung oder aus anderen Gründen erstellt werden, erfasst die Zusammenführung die Änderungen an anderer Stelle. Bei der Zusammenführung wird der Inhalt des Quellzweigs mit dem Zielzweig zusammengeführt. In diesem Prozess wird nur der Zielzweig geändert. Die Geschichte der Quellzweige bleibt unverändert.
Vorteile:- Einfachheit;
- bewahrt die vollständige Geschichte und chronologische Reihenfolge;
- pflegt einen Zweigkontext.
Nachteile:- Die Geschichte der Commits kann mit vielen Commits gefüllt (verschmutzt) werden.
- Das Debuggen mit Git Bisect kann schwieriger werden.
Wie kann man das machenFühren Sie den Hauptzweig 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 einen Verlauf beider Zweige enthält.
Git Rebase
Rebase ist eine weitere Möglichkeit, Änderungen von einem Zweig in einen anderen zu übertragen. Rebase komprimiert alle Änderungen in einem einzigen Patch. Anschließend wird der Patch in den Zielzweig integriert.
Im Gegensatz zum Zusammenführen wird beim Verschieben der Verlauf überschrieben, da abgeschlossene Arbeiten von einem Zweig in einen anderen übertragen werden. Der Prozess beseitigt die unerwünschte Geschichte.
Vorteile:- Vereinfacht eine möglicherweise komplexe Geschichte
- Vereinfachung von Manipulationen mit einem einzigen Commit
- Vermeiden Sie das Zusammenführen von Commits in ausgelasteten Repositorys und Zweigen
- Bereinigt Zwischen-Commits und macht sie zu einem einzigen Commit, was für DevOps-Befehle nützlich ist
Nachteile:- Durch das Komprimieren von Funktionen auf einige Commits wird der Kontext möglicherweise ausgeblendet
- Das Verschieben öffentlicher Repositorys kann bei der Arbeit in einem Team gefährlich sein
- Weitere Arbeit erscheint
- Für die Wiederherstellung mit gelöschten Zweigen ist ein Push erforderlich. Dies führt zu einer Aktualisierung aller Zweige mit demselben Namen, sowohl lokal als auch remote, und dies ist schrecklich.
Wenn Sie den Schritt falsch machen, ändert sich die Geschichte, und dies kann zu ernsthaften Problemen führen. Stellen Sie also sicher, dass Sie dies tun!
Wie kann man das machenVerschieben Sie den Feature-Zweig mit den folgenden Befehlen in den Hauptzweig.
$ git checkout feature $ git rebase master
Dadurch wird der gesamte Funktionszweig in den Hauptzweig verschoben. Der Verlauf des Projekts ändert sich. Für jedes Commit im Hauptzweig werden neue Commits erstellt.
Interaktive Bewegung
Auf diese Weise können Sie die Commits ändern, wenn sie in einen neuen Zweig verschoben werden. Dies ist besser als das automatische Verschieben, da es die vollständige Kontrolle über den Verlauf von Commits bietet. Wird normalerweise zum Löschen des Verlaufs verwendet, bevor der Feature-Zweig mit dem Master zusammengeführt wird.
$ git checkout feature $ git rebase -i master
Dadurch wird der Editor geöffnet, in dem alle Commits aufgelistet werden, die verschoben werden.
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3
Dies bestimmt genau, wie der Zweig nach dem Verschieben aussehen wird. Durch Anordnen von Objekten können Sie die Geschichte nach Ihren Wünschen gestalten. Sie können die
Befehle Fixup ,
Squash ,
Edit usw. verwenden.

Welches verwenden?
Was ist besser? Was empfehlen Experten?Es ist schwierig, die einzig richtige Entscheidung zu treffen, welche besser zu verwenden ist, da alle Teams unterschiedlich sind. Es hängt alles von den Bedürfnissen und Traditionen im Team ab.
Treffen Sie Entscheidungen basierend auf der Teamkompetenz in Git. Ist Ihnen die Einfachheit oder das Umschreiben der Geschichte wichtig oder vielleicht etwas anderes?
Was empfehle ich?Wenn das Team wächst, wird es schwierig, Entwicklungsänderungen durch eine Fusion zu verwalten oder zu verfolgen. Um einen sauberen und verständlichen Commit-Verlauf zu erhalten, ist es ratsam, Rebase zu verwenden.
Vorteile von Rebase:- Sie entwickeln sich lokal: wenn Sie Ihre Arbeit nicht mit anderen geteilt haben. Im Moment sollten Sie es vorziehen, das Zusammenführen zu verschieben, um Ihre Geschichte in Ordnung zu halten. Wenn Sie über eine persönliche Repository-Verzweigung verfügen, die nicht für andere Entwickler freigegeben ist, können Sie die Basis auch nach dem Umzug in Ihre Zweigstelle neu erstellen.
- Ihr Code kann überprüft werden: Sie haben eine Pull-Anforderung erstellt. Andere analysieren Ihre Arbeit und ziehen sie möglicherweise zur lokalen Überprüfung an ihren Stecker. Im Moment sollten Sie Ihre Arbeit nicht bewegen. Sie müssen ein Redo-Commit erstellen und den Zweig aktualisieren. Dies hilft dabei, Anfragen nach Pull-Anfragen zu verfolgen und ein versehentliches Brechen der Story zu verhindern.
- Die Überprüfung ist abgeschlossen und bereit für die Integration in den Zielzweig. Glückwunsch! Sie sind dabei, Ihren Feature-Zweig zu löschen. Angesichts der Tatsache, dass andere Entwickler diese Änderungen von nun an nicht mehr zusammenführen, ist dies Ihre Chance, Ihre Geschichte zu ändern. Zu diesem Zeitpunkt können Sie den Verlauf neu schreiben und die ursprünglichen Commits zurücksetzen. Diese lästigen „Änderungen“ und „Zusammenführungen“ werden zu einer kleinen Gruppe gezielter Commits zusammengeführt. Das Erstellen einer expliziten Zusammenführung für diese Commits ist optional, aber wichtig. Es zeichnet auf, wann die Funktion den Master erreicht hat.
Jetzt wissen Sie, obwohl unbedeutend, aber der Unterschied zwischen Merge und Rebase. Ich bin sicher, dass Sie die richtige Entscheidung treffen und das verwenden werden, was für Sie richtig ist.
Vergiss nicht: code = coffee + developer