Da in Git das branchen so wunderbar einfach ist, kann es einem schon mal passieren, dass gerade der falsche Branch ausgecheckt ist, wenn eine Änderung committed wird. Doch keine Bange, das Schöne an Versionskontrolle ist ja gerade, dass niemals irgendwas „kaputt“ geht. In diesem Artikel geht es also um die notwendigen Schritte, die unsere Änderung in den richtigen Branch befördern und den falschen Branch zurück setzen.
Die Nomenklatur dieses Artikels soll folgende sein:
richtigerBranch: Entspricht dem Branch, in den die Änderung eigentlich sollte.
falscherBranch: Entspricht dem Branch, in dem die Änderung irrtümlicherweise gelandet ist.
Änderung in den richtigen Branch kopieren
Zunächst müssen wir in den richtigen Branch wechseln
git checkout richtigerBranch
Jetzt übernehmen (cherry-pick) wir die Änderungen aus dem falschen Branch. Ich nehme an dieser Stelle an, dass es sich um genau den einen letzten commit handelt.
git cherry-pick falscherBranch
Und das war’s auch schon. Aktuell ist jetzt die Änderung in beiden Entwicklungszweigen.
Falschen Branch zurück setzen
Wir wechseln zunächst wieder in den „falschen“ Branch.
git checkout falscherBranch
Jetzt auf die Version vor der Änderung zurück setzen. Da wir hier einfach von der aktuellen Version (HEAD) eins zurück zählen können, müssen wir den Hash-Wert der Version nicht wissen.
git reset --hard HEAD~1
Wer etwas mehr Rückmeldung möchte, kann zunächst mit git reset --soft HEAD~1 die gemachten Änderungen noch behalten und prüfen was zurück gesetzt würde.
Jetzt noch ein normaler commit und wir sind fertig.
Was wenn ich auch noch gepusht hatte?
Solange es noch niemand mitbekommen hat, ist das egal. Dann müssen wir lediglich dem nächsten push etwas mehr Nachdruck verleihen und auch der remote branch stimmt wieder.
git push falscherBranch --force
Durch --force deaktivieren wir die Sperre, die dafür sorgt, dass beim push nur fast-forward möglich ist.
Wenn doch schon jemand unsere Änderung mitbekommen hat, sollten wir die Historie nicht durch einen reset durcheinander bringen. Hier empfiehlt es sich die Vorgängerversion noch einmal auszuchecken (dazu benötigen wir den Hash) und als neuen commit wieder hinten anzuhängen. Dann ist unser push wieder ganz normal fast-forward und konfliktfrei.