Git-Rebase: Alles, was Sie wissen müssen
Veröffentlicht: 2022-12-15
Der Git rebase Befehl kombiniert zwei Quellcode-Zweige zu einem. Der merge -Befehl von Git macht das auch. Wir erklären, was rebase macht, wie es verwendet wird und wann man stattdessen merge verwendet.
Die Git-Explosion
Was ist Git-Merge?
Was ist Git-Rebase?
So rebasieren Sie auf einen anderen Zweig
Git Rebase vs. Merge: Welche sollten Sie verwenden?
Rebasieren oder nicht rebasen?
Die Git-Explosion
Frustriert von anderen Versionskontrollsystemen und deren langsamen Updates und Commits, nahm sich Linus Torvalds, ein berühmter Linux-Kernel, 2005 einen Monat Zeit, um sein eigenes zu schreiben. Er nannte es Git.
Seiten wie GitHub, GitLab und BitBucket haben Git symbiotisch gefördert und davon profitiert. Heute wird Git weltweit verwendet, wobei 98 Prozent von 71.000 Befragten in einer Umfrage von 2022 Git als Versionskontrollsystem verwenden.
Eine der wichtigsten Designentscheidungen von Git war die Geschwindigkeit. Insbesondere die Arbeit mit Filialen musste so schnell wie möglich sein. Verzweigungen sind ein grundlegender Bestandteil von Versionskontrollsystemen. Ein Projekt-Repository hat einen Haupt- oder Master-Zweig. Hier befindet sich die Codebasis des Projekts. Die Entwicklung, wie z. B. neue Funktionen, findet in getrennten Seitenzweigen statt. Dadurch wird verhindert, dass die in Branches geleistete Arbeit den Master-Branch durcheinander bringt, und es ermöglicht die gleichzeitige Entwicklung in verschiedenen Teilen der Codebasis.
Wenn die Entwicklungen in den Nebenzweigen abgeschlossen sind, werden die Änderungen in den Master-Branch übertragen, indem der Entwicklungs-Branch in den Master-Branch gemergt wird. In anderen Versionskontrollsystemen war das Arbeiten mit Verzweigungen schwierig und rechenintensiv. Das Arbeiten mit Zweigen in Git ist sehr schnell und sehr leicht. Was in anderen Systemen einst eine mühsame und oft vermiedene Übung war, wurde in Git trivial.
Der Git rebase Befehl ist eine weitere Möglichkeit, die Änderungen von einem Branch in einen anderen Branch zu übertragen. Die merge und rebase Befehle haben ähnliche Ziele, aber sie erreichen ihre Ziele auf unterschiedliche Weise und liefern leicht unterschiedliche Ergebnisse.
Was ist Git-Merge?
Wozu also der Git- merge -Befehl? Angenommen, Sie haben einen Branch namens dev-branch erstellt, um an einem neuen Feature zu arbeiten.
Sie machen ein paar Commits und testen Ihr neues Feature. Es funktioniert alles gut. Jetzt möchten Sie Ihr neues Feature an den master Branch senden. Sie müssen sich im master Zweig befinden, um einen anderen mit ihm zusammenzuführen.
Wir können sicherstellen, dass wir uns im master Zweig befinden, indem wir ihn explizit auschecken, bevor wir zusammenführen.
git Checkout-Master
Wir können Git jetzt anweisen, den dev-branch mit dem Current-Branch, dem master -Branch, zusammenzuführen.
git merge dev-branch
Unsere merge ist für uns abgeschlossen. Wenn Sie den master Zweig auschecken und kompilieren, enthält er die neu entwickelte Funktion. Was Git tatsächlich durchgeführt hat, ist eine Drei-Wege-Zusammenführung. es vergleicht die neusten Commits in den Branches master und dev-branch und das Commit im master -branch unmittelbar vor der Erstellung des dev-branch . Anschließend führt es einen Commit auf dem master Zweig durch.
Zusammenführungen gelten als nicht destruktiv, da sie nichts löschen und nichts am Git-Verlauf ändern. Der dev-branch existiert noch, und keiner der vorherigen Commits wird geändert. Ein neuer Commit wird erstellt, der die Ergebnisse der Drei-Wege-Zusammenführung erfasst.
Nach der Zusammenführung sieht unser Git-Repository aus wie eine Zeitleiste mit einer alternativen Linie, die abzweigt und dann zur Hauptzeitleiste zurückkehrt.
Der dev-branch wurde in den master -Branch integriert.
Wenn Sie viele Verzweigungen in einem Projekt haben, kann die Historie des Projekts unübersichtlich werden. Dies ist oft der Fall, wenn ein Projekt viele Mitwirkende hat. Da sich der Entwicklungsaufwand in viele verschiedene Pfade aufteilt, ist die Entwicklungsgeschichte nicht linear. Das Entwirren des Commit-Verlaufs wird sogar noch schwieriger, wenn Zweige ihre eigenen Zweige haben.
Beachten Sie, dass Sie bei nicht festgeschriebenen Änderungen im master Zweig etwas mit diesen Änderungen tun müssen, bevor Sie etwas damit zusammenführen können. Sie könnten einen neuen Zweig erstellen und die Änderungen dort festschreiben und dann die Zusammenführung durchführen. Sie müssten dann Ihren temporären Zweig wieder mit dem Master-Branch zusammenführen.
Das funktioniert, aber Git hat einen Befehl, der dasselbe erreicht, ohne dass neue Branches erstellt werden müssen. Der Befehl stash speichert Ihre nicht festgeschriebenen Änderungen für Sie und lässt Sie sie mit stash pop .
Sie würden sie wie folgt verwenden:
verstauen git merge dev-branch Stash-Pop
Das Endergebnis ist ein zusammengeführter Zweig, in dem Ihre nicht gespeicherten Änderungen wiederhergestellt sind.
Was ist Git-Rebase?
Der Git rebase Befehl erreicht seine Ziele auf ganz andere Weise. Es nimmt alle Commits aus dem Zweig, den Sie rebasen werden, und spielt sie am Ende des Zweigs ab, auf den Sie rebasen.
In unserem vorherigen Beispiel sieht unser Git-Repository so aus, bevor wir eine Aktion durchgeführt haben. Wir haben einen Branch namens dev-branch und möchten diese Änderungen in den master -Branch verschieben.
Nach dem rebase sieht es aus wie eine einzige, vollständig lineare Zeitachse der Änderungen.
Der dev-branch wurde entfernt und die Commits im dev-branch wurden dem Master-Branch hinzugefügt. Das Endergebnis ist das gleiche, als ob die Commits im dev-branch tatsächlich direkt an den master -Branch übergeben worden wären. Die Commits werden nicht einfach an den master Branch geheftet, sie werden „replayed“ und frisch hinzugefügt.
Aus diesem Grund wird der rebase Befehl als destruktiv angesehen. Der rebasierte Branch existiert nicht mehr als separater Branch und der Git-Verlauf Ihres Projekts wurde neu geschrieben. Sie können zu einem späteren Zeitpunkt nicht mehr feststellen, welche Commits ursprünglich an den dev-branch gemacht wurden.
Es hinterlässt jedoch einen vereinfachten, linearen Verlauf. Im Vergleich zu einem Repository mit Dutzenden oder sogar Hunderten von Verzweigungen und Zusammenführungen, dem Lesen des Git-Protokolls oder der Verwendung einer grafischen Git-GUI, um ein Diagramm des Repositorys anzuzeigen, ist ein rebasiertes Repository ein Kinderspiel.
So rebasieren Sie auf einen anderen Zweig
Versuchen wir es mit einem git rebase Beispiel. Wir haben ein Projekt mit einem Branch namens new-feature . Wir würden diesen Branch wie folgt auf den master Branch rebase .
Zuerst überprüfen wir, ob der master Zweig keine ausstehenden Änderungen aufweist.
Git-Status
Wir checken den new-feature Zweig aus.
git checkout new-feature
Wir weisen Git an, den aktuellen Branch auf den Master-Branch rebase .
Git-Rebase-Master
Wir können sehen, dass wir noch zwei Zweige haben.
Git-Zweig
Wir wechseln zurück zum master Zweig
git Checkout-Master
Wir führen den New-Feature-Branch mit dem Current-Branch zusammen, der in unserem Fall der master Branch ist.
git merge new-feature
Interessanterweise haben wir nach der endgültigen Zusammenführung immer noch zwei Zweige.
Der Unterschied besteht darin, dass der Kopf des new-feature Zweigs und der Kopf des master -Zweigs jetzt so eingestellt sind, dass sie auf denselben Commit zeigen, und der Git-Verlauf zeigt nicht, dass es früher einen separaten new-feature Zweig gab, abgesehen davon das Filialkennzeichen.
Git Rebase vs. Merge: Welche sollten Sie verwenden?
Es geht nicht um rebase vs. merge . Sie sind beide mächtige Befehle und Sie werden sie wahrscheinlich beide verwenden. Allerdings gibt es Anwendungsfälle, in denen rebase nicht wirklich gut funktioniert. Das Aufheben von Fehlern, die durch Fehler beim merge verursacht werden, ist unangenehm, aber das Aufheben von Fehlern, die durch rebase verursacht werden, ist höllisch.
Wenn Sie der einzige Entwickler sind, der ein Repository verwendet, ist die Wahrscheinlichkeit geringer, dass Sie mit rebase etwas katastrophales tun. Sie könnten beispielsweise immer noch in die falsche Richtung rebase und Ihren Master-Branch auf Ihren new-feature Branch rebase . Um Ihren master Branch zurückzubekommen, müssten Sie erneut rebase , diesmal von Ihrem new-feature Branch auf Ihren master -Branch. Das würde Ihren master -Zweig wiederherstellen, wenn auch mit einem seltsam aussehenden Verlauf.
Verwenden rebase nicht für gemeinsam genutzte Branches, in denen andere wahrscheinlich funktionieren. Ihre Änderungen an Ihrem Repository werden vielen Leuten Probleme bereiten, wenn Sie Ihren rebasierten Code in Ihr Remote-Repository übertragen.
Wenn Ihr Projekt mehrere Mitwirkende hat, sollten Sie rebase nur in Ihrem lokalen Repository und nicht in öffentlichen Zweigen verwenden. Wenn Pull-Requests Teil Ihrer Codeüberprüfungen sind, verwenden Sie ebenfalls nicht rebase . Oder verwenden Sie zumindest kein rebase , nachdem Sie die Pull-Anforderung erstellt haben. Andere Entwickler sehen sich wahrscheinlich Ihre Commits an, was bedeutet, dass sich diese Änderungen in einem öffentlichen Zweig befinden, auch wenn sie sich nicht im master Zweig befinden.
Die Gefahr besteht darin, dass Sie Commits rebase , die bereits in ein Remote-Repository gepusht wurden, und andere Entwickler möglicherweise bereits auf diesen Commits gearbeitet haben. Ihr lokaler rebase wird diese bestehenden Commits verschwinden lassen. Wenn Sie diese Änderungen in das Repository schieben, werden Sie nicht beliebt sein.
Andere Mitwirkende müssen eine unordentliche merge durchlaufen, um ihre Arbeit zurück in das Repository zu verschieben. Wenn Sie dann ihre Änderungen zurück in Ihr lokales Repository ziehen, stehen Sie vor einem Durcheinander von doppelten Änderungen.
Rebasieren oder nicht rebasen?
Rebase könnte in Ihrem Projekt verboten sein. Es kann lokale, kulturelle Einwände geben. Einige Projekte oder Organisationen betrachten rebase als eine Form der Häresie und als Akt der Schändung. Einige Leute glauben, dass der Git-Verlauf eine unantastbare, dauerhafte Aufzeichnung dessen sein sollte, was passiert ist. rebase könnte also vom Tisch sein.
Lokal verwendet, in privaten Zweigen, ist rebase jedoch ein nützliches Werkzeug.
Pushen Sie, nachdem Sie rebasiert haben, und beschränken Sie es auf Branches, in denen Sie der einzige Entwickler sind. Oder zumindest, wo die gesamte Entwicklung aufgehört hat und niemand sonst irgendeine andere Arbeit auf den Commits Ihres Zweigs basiert hat.
Wenn Sie das tun, vermeiden Sie Probleme.
VERWANDT: So überprüfen und aktualisieren Sie Ihre Git-Version