Git Tutorial - Rebase

Jinku Hu 15 Februar 2024
  1. Was ist git rebase?
  2. Rebase Workflow
  3. Goldene Regel der Umbasierung
Git Tutorial - Rebase

Wir haben grundlegende Merges behandelt wie

  • Vorgezogene Verschmelzung

  • Dreiweg (rekursiv) verschmelzen

In diesem Tutorial werden wir eines der wichtigsten Features von Git vorstellen - das Rebasieren.

Was ist git rebase?

Rebasing bedeutet, dass Sie den Root-Commit von Branches ändern, die auf dem master Zweig basieren, oder anders gesagt, Sie setzen den Basis-Commit auf den letzten Commit des Branches zurück, den Sie zusammenführen wollen, wie master.

Lass uns sehen, wie das aussieht,

Git-Feature-Zweig

Wir haben die master und Feature Zweige in diesem Diagramm und während wir an unserem Feature Zweig arbeiteten, fuhren einige Leute damit fort, an master zu arbeiten.

Wir wollen unseren Zweig neu aufbauen, bevor wir ihn wieder in master einbinden, und wenn wir den Befehl rebase ausführen, ändert er die Übergabe, auf der unser Testzweig basiert, anstatt auf C3 statt auf C1 zu zeigen. Der folgende Graph zeigt, was nach der Rebase passiert.

Git-Feature-Zweig

Wenn wir die Änderungen zusammenführen, muss es nur wieder einen schnellen Vorwärts-Merge durchführen, weil die Commits nun auf dem letzten Commit von master basieren. Das ist der Grund, warum das Rebasieren eine der mächtigsten Funktionen von git ist.

Nachdem Sie diesen rebasierten Feature-Zweig in den master eingebunden haben, wird der Commit-Log-Graph wie folgt aussehen,

Git-Log-Graph nach dem Rebasieren

Es sieht so aus, als hätte der Feature Zweig nie existiert und alle Commit-Logs sind in der geraden Linie.

Rebase Workflow

  • Erstellen Sie den Feature-Zweig
   $ git checkout -b Feature
  • Änderungen an diesem Zweig vornehmen und übergeben
   $ git add modified.txt
   $ git commit -m 'coment here'
  • Rebase feature branch on master
   $ git rebase master
  • Merge the rebased feature branch on master
   $ git checkout master
   $ git merge Feature

Goldene Regel der Umbasierung

Die goldene Regel ist, niemals einen Zweig, den man öffentlich zugänglich gemacht hat, wegen der Neuschreibung der Geschichte neu zu gründen.

Wenn Sie einen öffentlichen Zweig rebasieren und jemand diesen Zweig bearbeitet, nachdem Sie ihn rebasiert haben, wird es sehr schwierig sein, diese neuen Änderungen in Ihren master-Zweig zu bekommen, da die anderen Entwickler immer noch mit dem ursprünglichen master-Zweig arbeiten.

Autor: Jinku Hu
Jinku Hu avatar Jinku Hu avatar

Founder of DelftStack.com. Jinku has worked in the robotics and automotive industries for over 8 years. He sharpened his coding skills when he needed to do the automatic testing, data collection from remote servers and report creation from the endurance test. He is from an electrical/electronics engineering background but has expanded his interest to embedded electronics, embedded programming and front-/back-end programming.

LinkedIn Facebook