Rebasing ist der Prozess des Verschiebens oder Kombinierens einer Folge von Commits zu einem neuen Basis-Commit. Rebasing ist am nützlichsten und am einfachsten im Kontext eines Feature-Branching-Workflows zu visualisieren. Der allgemeine Prozess kann wie folgt visualisiert werden:

Aus inhaltlicher Sicht ändert Rebasing die Basis Ihres Zweigs von einem Commit zu einem anderen, sodass es so aussieht, als hätten Sie Ihren Zweig aus einem anderen Commit erstellt., Intern erreicht Git dies, indem neue Commits erstellt und auf die angegebene Basis angewendet werden. Es ist sehr wichtig zu verstehen, dass der Zweig, obwohl er gleich aussieht, aus völlig neuen Commits besteht.

Verwendung

Der Hauptgrund für das Rebasing ist die Aufrechterhaltung eines linearen Projektverlaufs. Betrachten Sie beispielsweise eine Situation, in der der Master-Zweig seit Beginn der Arbeit an einem Feature-Zweig fortgeschritten ist., Sie möchten die neuesten Updates für den Master-Zweig in Ihrem Feature-Zweig erhalten, aber Sie möchten den Verlauf Ihres Zweigs sauber halten, damit es so aussieht, als hätten Sie den neuesten Master-Zweig bearbeitet. Dies bietet den späteren Vorteil einer sauberen Zusammenführung Ihres Feature-Zweigs zurück in den Master-Zweig. Warum wollen wir eine „saubere Geschichte“ pflegen? Die Vorteile einer sauberen Historie werden greifbar, wenn Git-Operationen durchgeführt werden, um die Einführung einer Regression zu untersuchen. Ein realistischeres Szenario wäre:

1. Im Master-Zweig wird ein Fehler identifiziert., Eine Funktion, die erfolgreich funktioniert hat, ist jetzt defekt.
2. Ein Entwickler untersucht den Verlauf des Master-Zweigs mit aufgrund des“ clean history “ kann der Entwickler schnell über den Verlauf des Projekts nachdenken.
3. Der Entwickler kann nicht erkennen, wann der Fehler mit git log wurde, sodass der Entwickler eine git bisectausführt.
4. Da der Git-Verlauf sauber ist, verfügt git bisect über einen verfeinerten Satz von Commits, die bei der Suche nach der Regression verglichen werden müssen., Der Entwickler findet schnell das Commit, das den Fehler eingeführt hat, und kann entsprechend handeln.

Erfahren Sie mehr über git log und git bisect auf ihren individuellen Benutzungsseiten.

Sie haben zwei Möglichkeiten, Ihre Funktion in den Master-Zweig zu integrieren: Direkt zusammenführen oder Rebasing und dann Zusammenführen. Die erstere Option führt zu einer 3-Wege-Zusammenführung und einem Merge-Commit, während die letztere zu einer Schnellvorlauf-Zusammenführung und einem perfekt linearen Verlauf führt. Das folgende Diagramm zeigt, wie das Rebasing auf den Masterzweig eine schnelle Zusammenführung ermöglicht.,

Rebasing ist eine gängige Methode, um Upstream-Änderungen in Ihr lokales Repository zu integrieren. Das Ziehen von Upstream-Änderungen mit Git Merge führt jedes Mal zu einem überflüssigen Merge-Commit, wenn Sie sehen möchten, wie das Projekt fortgeschritten ist. Auf der anderen Seite ist Rebasing wie zu sagen: „Ich möchte meine Änderungen auf das stützen, was alle bereits getan haben.“

Nicht rebase öffentlichen Verlauf

Wie wir zuvor in rewriting History diskutiert haben, sollten Sie nie rebase Commits, sobald sie in ein öffentliches Repository verschoben wurden., Die Rebase würde die alten Commits durch neue ersetzen und es würde so aussehen, als wäre dieser Teil Ihrer Projekthistorie plötzlich verschwunden.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive ist, dass git rebase akzeptiert ein -- i argument. Dies steht für “ Interaktiv.“Ohne Argumente wird der Befehl im Standardmodus ausgeführt. Nehmen wir in beiden Fällen an, wir haben einen separaten Feature-Zweig erstellt.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase im Standardmodus übernimmt automatisch die Commits in Ihrem aktuellen Arbeitszweig und wendet sie auf den Kopf des übergebenen Zweigs an.

 git rebase 

Dadurch wird der aktuelle Zweig automatisch auf umgestellt, was jede Art von Commit-Referenz sein kann (z. B. eine ID, ein Zweigname, ein Tag oder ein relativer Verweis auf HEAD).

Das Ausführen von git rebase mit dem Flag -i beginnt eine interaktive Rebasing-Sitzung., Anstatt alle Commits blind auf die neue Basis zu verschieben, bietet Ihnen das interaktive Rebasing die Möglichkeit, einzelne Commits zu ändern. Auf diese Weise können Sie den Verlauf bereinigen, indem Sie eine vorhandene Reihe von Commits entfernen, aufteilen und ändern. Es ist wie Git commit --amend auf Steroiden.

 git rebase --interactive 

Dies setzt den aktuellen Zweig auf um, verwendet jedoch eine interaktive Rebasing-Sitzung. Dadurch wird ein Editor geöffnet, in dem Sie Befehle (siehe unten) für jedes Commit eingeben können, das neu gestartet werden soll., Diese Befehle bestimmen, wie einzelne Commits auf die neue Basis übertragen werden. Sie können die Commit-Liste auch neu anordnen, um die Reihenfolge der Commits selbst zu ändern. Sobald Sie Befehle für jedes Commit in der Rebase angegeben haben, beginnt Git mit der Wiedergabe von Commits, die die Rebase-Befehle anwenden. Die Rebasing-Bearbeitungsbefehle lauten wie folgt:

Zusätzliche Rebase-Befehle

Wie auf der Seite zum Umschreiben des Verlaufs beschrieben, kann das Rebasing verwendet werden, um ältere und mehrere Commits, festgeschriebene Dateien und mehrere Nachrichten zu ändern., Während dies die häufigsten Anwendungen sind, verfügt git rebase auch über zusätzliche Befehlsoptionen, die in komplexeren Anwendungen nützlich sein können.

• git rebase -- d bedeutet, dass das Commit während der Wiedergabe aus dem endgültigen kombinierten Commit-Block verworfen wird.
• git rebase -- p lässt das Commit unverändert. Die Nachricht oder der Inhalt des Commits werden nicht geändert und es handelt sich weiterhin um ein einzelnes Commit im Verlauf der Verzweigungen.
• git rebase -- x führt während der Wiedergabe bei jedem markierten Commit ein Kommandozeilen-Shell-Skript aus., Ein nützliches Beispiel wäre, die Testsuite Ihrer Codebasis für bestimmte Commits auszuführen, um Regressionen während einer Rebase zu identifizieren.

Rekapitulieren

Interaktives Rebasing gibt Ihnen die vollständige Kontrolle darüber, wie Ihr Projektverlauf aussieht. Dies bietet Entwicklern viel Freiheit, da sie einen „unordentlichen“ Verlauf festlegen können, während sie sich auf das Schreiben von Code konzentrieren, und ihn dann wieder bereinigen.

Die meisten Entwickler verwenden gerne eine interaktive Rebase, um einen Feature-Zweig zu polieren, bevor sie ihn in die Hauptcodebasis einfügen., Dies gibt ihnen die Möglichkeit, unbedeutende Commits zu löschen, veraltete Commits zu löschen und sicherzustellen, dass alles andere in Ordnung ist, bevor sie sich zum „offiziellen“ Projektverlauf verpflichten. Für alle anderen wird es so aussehen, als ob das gesamte Feature in einer einzigen Reihe gut geplanter Commits entwickelt wurde.

Die wirkliche Kraft des interaktiven Rebasing kann in der Geschichte des resultierenden Master-Zweiges gesehen werden. Für alle anderen sieht es so aus, als wären Sie ein brillanter Entwickler, der die neue Funktion beim ersten Mal mit der perfekten Menge an Commits implementiert hat., Auf diese Weise kann interaktives Rebasing die Historie eines Projekts sauber und aussagekräftig halten.

Konfigurationsoptionen

Es gibt einige Rebase-Eigenschaften, die mit git configfestgelegt werden können. Diese Optionen ändern das Aussehen der git rebase Ausgabe.

• rebase.stat: Ein boolescher Wert, der ist standardmäßig auf false festgelegt. Die Option schaltet die Anzeige des visuellen Diffstat-Inhalts um, der anzeigt, was sich seit der letzten Debase geändert hat.

• rebase.autoSquash: Ein boolescher Wert, der das Verhalten --autosquash umschaltet.,

• rebase.missingCommitsCheck: Kann auf mehrere Werte gesetzt werden, die das Rebase-Verhalten bei fehlenden Commits ändern.,/tr>
  

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Im git rebase--onto – Modus wird der Befehl erweitert auf:

    git rebase --onto 

  Der--onto – Befehl ermöglicht eine leistungsfähigere Form oder Rebase, die es ermöglicht, bestimmte Refs als Spitzen einer Rebase zu übergeben.Nehmen wir an, wir haben ein Beispiel-Repo mit Zweigen wie:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB basiert auf featureA, wir erkennen jedoch, dass featureB nicht von einer der Änderungen in featureA abhängig ist und nur vom Master verzweigt werden kann.

    git rebase --onto master featureA featureB 

  featureA ist die ., master wird zur und featureB ist eine Referenz für das, worauf HEAD der zeigt. Die Ergebnisse sind dann:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  Verständnis der Gefahren von Rebase

  Eine Einschränkung, die bei der Arbeit mit Git Rebase zu beachten ist, dass Mergekonflikte während eines Rebase-Workflows häufiger auftreten können. Dies geschieht, wenn Sie einen langlebigen Zweig haben, der vom Master abgewichen ist., Schließlich möchten Sie gegen Master rebasieren und zu diesem Zeitpunkt kann es viele neue Commits enthalten, mit denen Ihre Verzweigungsänderungen in Konflikt stehen können. Dies kann leicht behoben werden, indem Sie Ihren Zweig häufig gegen Master neu erstellen und häufigere Commits vornehmen. Die Befehlszeilenargumente --continue und --abort können an git rebase übergeben werden, um die Rebase bei Konflikten voranzutreiben oder zurückzusetzen.

  Eine schwerwiegendere Einschränkung der Rebase geht durch Commits beim Umschreiben des interaktiven Verlaufs verloren., Wenn Sie Rebase im interaktiven Modus ausführen und Unterbefehle wie Squash oder drop ausführen, werden Commits aus dem unmittelbaren Protokoll Ihres Computers entfernt. Auf den ersten Blick kann dies so aussehen, als wären die Commits dauerhaft verschwunden. Mit git reflog können diese Commits wiederhergestellt und die gesamte Rebase rückgängig gemacht werden. Weitere Informationen zur Verwendung von git reflog um verlorene Commits zu finden, besuchen Sie unsere Git reflog-Dokumentationsseite.

  Git Rebase selbst ist nicht ernsthaft gefährlich., Die wirklichen Gefahrenfälle treten auf, wenn Sie interaktive Rebases ausführen oder neu schreiben und die Ergebnisse an einen Remote-Zweig senden, der von anderen Benutzern gemeinsam genutzt wird. Dies ist ein Muster, das vermieden werden sollte, da es die Arbeit anderer Remote-Benutzer beim Ziehen überschreiben kann.

  Wiederherstellen von Upstream-Rebase

  Wenn ein anderer Benutzer rebased und force pushed auf den Zweig, den Sie begehen, a git pull überschreibt dann alle Commits, die Sie basierend auf diesem vorherigen Zweig mit der Spitze haben, die force pushed war., Glücklicherweise können Sie mit git reflog den reflog des Remote-Zweigs abrufen. Im Reflog des Remote-Zweigs finden Sie einen Ref, bevor er neu gestaffelt wurde. Anschließend können Sie Ihren Zweig mit der Option --onto wie oben im Abschnitt Erweiterte Rebase-Anwendung beschrieben, gegen diesen Remote-Ref neu erstellen.

  Zusammenfassung

  In diesem Artikel haben wir die Verwendung von git rebase behandelt. Wir diskutierten grundlegende und erweiterte Anwendungsfälle und erweiterte Beispiele., Einige wichtige Diskussionspunkte sind:

  • git rebase standard vs interaktive Modi
  • git rebase Konfigurationsoptionen
  • git rebase –onto
  • git rebase lost commits