Die sichere Methode zum Rebase in Git.
Der Git- rebaseBefehl kombiniert zwei Quellcode-Zweige zu einem. Der git rebase Befehl macht das auch. Wir erklären, was er rebasetut, wie er verwendet wird und wann man mergestattdessen verwenden sollte.
Die Git-Explosion
Linus Torvalds , der berühmte Linux-Kernel-Entwickler, war frustriert über andere Versionskontrollsysteme und deren langsame Updates und Commits und nahm sich 2005 einen Monat Zeit, um sein eigenes System zu schreiben. Er nannte es Git.
Websites wie GitHub , GitLab und BitBucket haben Git symbiotisch gefördert und davon profitiert. Heute wird Git weltweit verwendet. In einer Umfrage aus dem Jahr 2022 gaben 98 Prozent von 71.000 Befragten an, Git als Versionskontrollsystem zu verwenden.
Eine der wichtigsten Designentscheidungen von Git war die Geschwindigkeit. Insbesondere musste die Arbeit mit Zweigen so schnell wie möglich erfolgen. Zweige sind ein grundlegender Bestandteil von Versionskontrollsystemen. Ein Projekt-Repository hat einen Haupt- oder Master-Zweig. Hier befindet sich die Codebasis des Projekts. Die Entwicklung, beispielsweise neuer Funktionen, erfolgt in getrennten Nebenzweigen. Dies verhindert, dass die in den Zweigen geleistete Arbeit den Master-Zweig durcheinander bringt, und ermöglicht die gleichzeitige Entwicklung in verschiedenen Teilen der Codebasis.
Wenn die Entwicklungen in den Nebenzweigen abgeschlossen sind, werden die Änderungen in den Hauptzweig übertragen, indem der Entwicklungszweig in den Hauptzweig integriert wird. In anderen Versionskontrollsystemen war das Arbeiten mit Zweigen schwierig und rechenintensiv. Das Arbeiten mit Zweigen in Git ist sehr schnell und sehr einfach. Was in anderen Systemen einst eine mühsame und oft vermiedene Übung war, ist in Git trivial geworden.
Der Git- rebaseBefehl ist eine weitere Möglichkeit, Änderungen von einem Zweig in einen anderen zu übertragen. Die Befehle mergeund rebasehaben ähnliche Ziele, erreichen ihre Ziele jedoch auf unterschiedliche Weise und führen zu leicht unterschiedlichen Ergebnissen.
Was ist git rebase?
Wozu dient also der git rebaseBefehl ? Angenommen, Sie haben einen Zweig namens erstellt, dev-branchum an einer neuen Funktion zu arbeiten.
Sie führen ein paar Commits durch und testen Ihre neue Funktion. Alles funktioniert gut. Jetzt möchten Sie Ihre neue Funktion an den masterZweig senden. Sie müssen sich im masterZweig befinden, um eine weitere Funktion darin zusammenführen zu können.
Wir können sicherstellen, dass wir uns im master Zweig befinden, indem wir ihn vor dem Zusammenführen explizit auschecken.
Wir können Git jetzt anweisen, es dev-branchin den aktuellen Zweig zu integrieren, also in den masterZweig.
Unser mergeist für uns abgeschlossen. Wenn Sie den masterZweig 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 aktuellsten Commits in den masterund dev-branchZweigen und das Commit im masterZweig unmittelbar vor der dev-branchErstellung. Anschließend führt es ein Commit für den masterZweig aus.
Zusammenführungen gelten als zerstörungsfrei, da sie nichts löschen und den Git-Verlauf nicht ändern. Das dev-branchCommit ist weiterhin vorhanden und keines der vorherigen Commits wird geändert. Es wird ein neues Commit erstellt, das die Ergebnisse der Drei-Wege-Zusammenführung erfasst.
Nach der Zusammenführung sieht unser Git-Repository wie eine Zeitleiste aus, von der eine alternative Linie abzweigt und dann zur Hauptzeitleiste zurückkehrt.
Die dev-branchZweigniederlassung wurde in die masterFiliale eingegliedert.
Wenn Sie in einem Projekt viele Zweige haben, kann der Verlauf des Projekts verwirrend werden. Dies ist häufig der Fall, wenn ein Projekt viele Mitwirkende hat. Da sich die Entwicklungsanstrengungen auf viele verschiedene Pfade aufteilen, ist der Entwicklungsverlauf nicht linear. Das Entwirren des Commit-Verlaufs wird noch schwieriger, wenn Zweige ihre eigenen Zweige haben.
Beachten Sie, dass Sie, wenn Sie nicht festgeschriebene Änderungen im masterZweig haben, etwas mit diesen Änderungen tun müssen, bevor Sie etwas darin zusammenführen können. Sie könnten einen neuen Zweig erstellen, die Änderungen dort festschreiben und dann die Zusammenführung durchführen. Anschließend müssten Sie Ihren temporären Zweig wieder in den Master-Zweig zusammenführen.
Das funktioniert, aber Git hat einen Befehl, der dasselbe erreicht, ohne dass neue Zweige erstellt werden müssen. Der stashBefehl speichert Ihre nicht festgeschriebenen Änderungen für Sie und ermöglicht Ihnen, sie mit wieder aufzurufen stash pop.
Sie würden sie folgendermaßen verwenden:
Das Endergebnis ist ein zusammengeführter Zweig, in dem Ihre nicht gespeicherten Änderungen wiederhergestellt wurden.
Was ist Git Rebase?
Der Git- rebaseBefehl erreicht seine Ziele auf eine völlig andere Weise. Er nimmt alle Commits des Branch, den Sie rebasieren möchten, und spielt sie am Ende des Branch, auf den Sie rebasieren, erneut ab.
In unserem vorherigen Beispiel sieht unser Git-Repository vor der Ausführung einer Aktion folgendermaßen aus. Wir haben einen Zweig namens dev-branchund möchten diese Änderungen in den masterZweig verschieben.
Danach rebasesieht es wie eine einzelne, vollständig lineare Zeitleiste der Änderungen aus.
Das dev-branchwurde entfernt und die Commits im dev-branchwurden dem Master-Zweig hinzugefügt. Das Endergebnis ist dasselbe, als ob die Commits im von Anfang an dev-branchdirekt in den Zweig übernommen worden wären master. Die Commits werden nicht einfach an den masterZweig angehängt, sondern „wiedergegeben“ und neu hinzugefügt.
Aus diesem Grund rebasewird der Befehl als destruktiv angesehen. Der rebasierte Zweig existiert nicht mehr als separater Zweig und der Git-Verlauf Ihres Projekts wurde neu geschrieben. Sie können zu einem späteren Zeitpunkt nicht mehr feststellen, welche Commits ursprünglich vorgenommen wurden dev-branch.
Sie erhalten jedoch einen vereinfachten, linearen Verlauf. Im Vergleich zu einem Repository mit Dutzenden oder sogar Hunderten von Zweigen und Zusammenführungen ist ein rebasiertes Repository ein Kinderspiel, wenn Sie das Git-Protokoll lesen oder eine grafische Git-Benutzeroberfläche verwenden, um ein Diagramm des Repositorys anzuzeigen.
So führen Sie ein Rebase auf einem anderen Zweig durch
Versuchen wir es mit einem git rebase Beispiel. Wir haben ein Projekt mit einem Zweig namens new-feature. Wir haben rebase diesen Zweig masterwie folgt auf den Zweig gelegt.
Zunächst prüfen wir, dass im masterZweig keine Änderungen ausstehen.
Wir checken die new-featureFiliale aus.
Wir weisen Git an, rebaseden aktuellen Zweig auf den Master-Zweig zu verschieben.
Wir können sehen, dass wir immer noch zwei Zweige haben.
Wir wechseln zurück zum masterZweig
Wir führen den Zweig mit den neuen Funktionen in den aktuellen Zweig zusammen, der in unserem Fall der masterZweig ist.
Interessanterweise haben wir nach der endgültigen Zusammenführung immer noch zwei Zweige.
Der Unterschied besteht darin, dass der Kopf des new-featureZweigs und der Kopf des masterZweigs jetzt so eingestellt sind, dass sie auf dasselbe Commit verweisen, und der Git-Verlauf zeigt new-featureabgesehen von der Zweigbezeichnung nicht an, dass es früher einen separaten Zweig gab.
Git Rebase vs. Merge: Was sollten Sie verwenden?
Es ist kein Fall von rebasevs. merge. Beides sind leistungsstarke Befehle und Sie werden sie wahrscheinlich beide verwenden. Allerdings gibt es Anwendungsfälle, in denen rebasenicht so gut funktioniert. Fehler zu beheben, die durch Fehler bei der Verwendung verursacht wurden, mergeist unangenehm, aber Fehler zu beheben, die durch verursacht wurden, rebaseist die Hölle.
Wenn Sie der einzige Entwickler sind, der ein Repository verwendet, ist die Wahrscheinlichkeit geringer, dass Sie damit etwas rebaseDesaströses tun. Sie könnten rebasebeispielsweise immer noch in die falsche Richtung gehen und rebaseIhren Master-Zweig auf Ihren new-featureZweig verschieben. Um Ihren masterZweig zurückzubekommen, müssten Sie dies rebaseerneut tun, diesmal von Ihrem new-featureZweig zu Ihrem masterZweig. Dadurch würde Ihr Zweig wiederhergestellt master, allerdings mit einer seltsam aussehenden Historie.
Verwenden Sie es nicht rebasein freigegebenen Zweigen, in denen wahrscheinlich auch andere daran arbeiten. 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, ist es am sichersten, nur rebasein Ihrem lokalen Repository und nicht in öffentlichen Zweigen zu verwenden. Wenn Pull Requests Teil Ihrer Codeüberprüfungen sind, verwenden Sie ebenfalls nicht rebase. Oder verwenden Sie es zumindest nicht, rebasenachdem Sie den Pull Request erstellt haben. Andere Entwickler sehen sich wahrscheinlich Ihre Commits an, was bedeutet, dass diese Änderungen in einem öffentlichen Zweig sind, auch wenn sie nicht in dem masterZweig sind.
Die Gefahr besteht darin, dass Sie Commits verwenden rebase, die bereits in ein Remote-Repository übertragen wurden, und andere Entwickler haben möglicherweise bereits auf diesen Commits gearbeitet. Ihr lokales Repository rebaselässt diese vorhandenen Commits verschwinden. Wenn Sie diese Änderungen in das Repository übertragen, werden Sie nicht beliebt sein.
Andere Mitwirkende müssen einen ganzen Haufen Arbeit auf sich nehmen, mergeum ihre Arbeit wieder in das Repository zu übertragen. Wenn Sie dann deren Änderungen wieder in Ihr lokales Repository übertragen, stehen Sie vor der Aufgabe, ein Durcheinander doppelter Änderungen zu entwirren memoji 2.
Rebase durchführen oder nicht rebase?
Rebasekönnte in Ihrem Projekt verboten sein. Es könnte lokale, kulturelle Einwände geben. Manche Projekte oder Organisationen betrachten es rebaseals eine Form der Ketzerei und einen Akt der Entweihung. Manche Leute glauben, dass die Git-Historie eine unantastbare, dauerhafte Aufzeichnung dessen sein sollte, was passiert ist. Das rebasekönnte also vom Tisch sein.
Bei lokaler Verwendung auf privaten Zweigstellen ist es jedoch rebaseein nützliches Werkzeug.
Führen Sie Push aus, nachdem Sie ein Rebased durchgeführt haben, und beschränken Sie es auf Zweige, in denen Sie der einzige Entwickler sind. Oder zumindest auf Zweige, in denen die gesamte Entwicklung gestoppt wurde und niemand sonst andere Arbeiten auf den Commits Ihres Zweigs basiert hat.
Wenn Sie das tun, können Sie etwaige Probleme vermeiden.