Grundlagen des Rebasings

Einen Commit auf dem main-Branch machen

Lassen Sie uns damit beginnen, einen Commit direkt im Remote-main-Branch zu machen, indem wir die Datei README.md im Remote-Repository bearbeiten. Dies wird dazu führen, dass der main-Branch und der feature/payment-Branch eine auseinanderlaufende Commit-Historie haben.

Hier ist die Zeile, die zur Datei hinzugefügt wurde:

Hier ist die entsprechende Commit-Nachricht:

Verständnis von Rebasing

Wie wir im vorherigen Kapitel erwähnt haben, kann und sollte der Feature-Branch, nachdem er überprüft und getestet wurde, wieder in den main-Branch zusammengeführt werden. Bis jetzt haben wir dafür nur den Befehl git merge verwendet. Eine andere Methode ist jedoch die Verwendung des Befehls git rebase.

Wenn wir einen Branch erstellen, verfolgt Git den letzten Commit auf beiden Branches. Wenn nur ein Branch neue Änderungen hat, kann Git diese schnell vorwärts bringen und anwenden. Wenn jedoch beide Branches neue Änderungen haben, erstellt Git einen neuen Merge-Commit, was zu einem Drei-Wege-Merge führt.

So würde ein Drei-Wege-Merge in unserem Fall aussehen, bei dem C4 der letzte Commit auf dem feature/payment Branch vor dem Merging war:

Drei-Wege-Merges können jedoch das Debuggen erschweren, da sie eine geteilte, nicht-lineare Historie erzeugen. Durch das Rebasen ändern wir die Basis unserer Commits und spielen sie auf der neuen Basis erneut ab, sodass Git einen Fast-Forward-Merge durchführen und eine lineare Historie beibehalten kann.

Hier ist eine Animation, die veranschaulicht, wie Rebasing in unserem Fall durchgeführt werden kann (die Commit-Bezeichner entsprechen hier nicht den realen):