Git-Rebase-Zweig mit allen übergeordneten Zweigen (oder abhängigen Unterzweigen)

Ist es möglich, einen Branch mit allen übergeordneten Branches mit Git zu rebasen? (Ich denke, “übergeordnete Zweige” ist die richtige Form, die hier verwendet werden sollte. Abhängig von Ihrer Sichtweise können Sie sie auch als abhängige Unterzweige bezeichnen. Wenn Sie jedoch den übergeordneten Zeigern der Commits folgen, gelangen Sie zu diesen Zweigen, also meiner Meinung nach ist fair, sie “Elternzweige” zu nennen).

Ich verwende Branches oft als schnelle/änderbare Tags/Checkpoints, um bestimmte Commits zu markieren. Alle übergeordneten Branches/Eltern-Referenzen sind vollständig in den zu rebasierenden Branch eingeschlossen; Es gibt keine Commits nur in den übergeordneten Zweigen.

* master
*
* featureA-finished
*
* origin/master

Jetzt will ich rebase -i master auf zu origin/master um den Commit zu ändern/umzuformulieren featureA-finished^

Nach git rebase -i --onto origin/master origin/master masterich möchte im Grunde, dass die Geschichte lautet:

* master
*
* featureA-finished
* (changed/reworded)
* origin/master

aber was ich bekomme ist:

* master
*
* (same changeset as featureA-finished)
* (changed/reworded)
| * featureA-finished
|.* (original commit i wanted to edit)
* origin/master

Gibt es einen Ausweg, oder stecke ich damit fest, alle übergeordneten Branches – genauer gesagt die Branch-Labels – auf den neuen, rebasierten Commits neu zu erstellen?

Diese Frage hängt mit dem Rebasing eines Zweigs einschließlich aller seiner untergeordneten Elemente zusammen, unterscheidet sich aber dennoch stark davon.

Laut Git Objektmodell Wenn Sie nur die Metadaten eines Commit (dh Commit-Nachricht) ändern, aber nicht die zugrunde liegenden Daten (“Baum(e)”), die darin enthalten sind, bleibt sein Baum-Hash unverändert.

Abgesehen von der Bearbeitung einer Commit-Nachricht führen Sie auch einen Rebase durch, der die Tree-Hashes jedes Commits in Ihrem Verlauf ändert, da alle Änderungen daraus gezogen werden origin/master wirkt sich auf die Dateien in Ihrem neu geschriebenen Verlauf aus: was bedeutet, dass sich einige der Dateien (Blobs) geändert haben, auf die Ihr Commit verweist.

Es gibt also keine kugelsichere Möglichkeit, das zu tun, was Sie wollen.

Das heißt, ein Commit bearbeiten mit rebase -i ändert normalerweise den Zeitstempel und Autor des Commits nicht, sodass Sie dies verwenden könnten, um Ihre Commits vor und nach einer Rebase-Operation eindeutig zu identifizieren.

Sie müssten ein Skript schreiben, das alle Verzweigungsstartpunkte gegen diese „timestamp:author“-Kennung aufzeichnet, bevor Sie eine Rebase durchführen, und dann die umgeschriebenen Commits mit derselben „timestamp:author“-ID finden und den Branch darauf rebasen.

Leider habe ich jetzt keine Zeit, dieses Skript selbst zu schreiben, also kann ich Ihnen nur viel Glück wünschen!

Bearbeiten: Sie können die E-Mail-Adresse und den Zeitstempel des Autors abrufen unter:

$ git log --graph --all --pretty=format:"%h %ae:%ci"
* 53ca31a [email protected]:2010-06-16 13:50:12 +0100
* 03dda75 [email protected]:2010-06-16 13:50:11 +0100
| * a8bb03a [email protected]:2010-06-16 13:49:46 +0100
| * b93e59d [email protected]:2010-06-16 13:49:44 +0100
|/
* d4214a2 [email protected]:2010-06-16 13:49:41 +0100

Und Sie können eine Liste der Zweige für jeden dieser Zweige basierend auf ihrem Commit-Hash erhalten:

$ git branch --contains 03dda75
* testbranch

Achten Sie auf mehrere Branches pro Commit, den gemeinsamen Vorfahren d4214a2 gehört beiden Sparten an!

Sieht so aus, als ob diese Funktion langsam in Git Einzug hält. rebase wird die Option erhalten --rebase-refs was genau das tun wird, was meine ursprüngliche Antwort gefragt hat. Für die vorgeschlagene Patch-Serie siehe den Thread rebase: Befehl “ref” und Optionen –rewrite-{refs,heads,tags} auf gmane.

Aktualisierung 2022:

Die Option --update-refs ist endlich in Git v2.38.0 gelandet, das jetzt genau das kann, was vor mehr als 12 Jahren in der Ausgangsfrage gestellt wurde 🙂

Diese Funktion wurde mit Commit zusammengeführt 3d8e3dc4fc22fe41f8ee1184f085c600f35ec76f im August. Hurra!

Ich bin mir nicht sicher, wie genau du darauf gekommen bist, aber:

git branch -f (same changeset as featureA-finished)

sollte ausreichen, um Ihren zurückzusetzen featureA-finished Zweig mit der richtigen Geschichte.

Was ich raten würde, ist zu rebase featureA-finished auf zu origin/master erste. Führen Sie dann den Umformulierungsschritt durch. Danach rebasieren master auf zu featureA-finished. Dadurch erhalten Sie das gewünschte Endergebnis.

Beachten Sie, dass Sie verwenden müssen -i auf beiden Rebases und müssen möglicherweise alle Commits aus dem Original löschen featureA-finshed unten in der zweiten rebase. Wenn Sie wollten, könnten Sie ein Skript schreiben, das dies beseitigt, indem Sie den Zwischenzweig speichern und diesen als Basis für eine Rebase verwenden --onto die neue Version. Es könnte sogar eine Folge solcher “Unterzweige” handhaben, wenn Sie es richtig geschrieben haben. Wenn Sie Hilfe brauchen, kann ich versuchen, einen herauszuschlagen.