Commits aus einem Branch in Git löschen

Lesezeit: 8 Minuten

Commits aus einem Branch in Git loschen
hap497

Ich würde gerne wissen, wie man einen Commit löscht.

Durch deleteich meine, es ist, als hätte ich diesen Commit nicht vorgenommen, und wenn ich in Zukunft einen Push durchführe, werden meine Änderungen nicht in den Remote-Zweig übertragen.

Ich habe git help gelesen und denke, der Befehl, den ich verwenden sollte, ist git reset --hard HEAD. Ist das richtig?

  • Ich denke das ist nicht ein Duplikat von Git undo last commit, da es fragt, wie es gelöscht werden soll irgendein Commit aus einem Branch. Ich denke auch, dass keine der Antworten diese Frage tatsächlich anspricht. Sie spulen alle die letzten Commits zurück, nicht cherry-pick und delete ein einzelnes Commit, das vor einiger Zeit stattgefunden haben kann.

    – Chris

    3. Mai 2015 um 18:06 Uhr

  • @Chris, die Antwort mit git rebase -i HEAD~10 adressiert die Frage, da Sie Commits zum Löschen willkürlich auswählen können. Git wendet die Commits in dem von Ihnen angegebenen Bereich nacheinander an und ignoriert Commits, die Sie aus dem Protokoll entfernt haben. Ich habe diesen Befehl heute verwendet, um die zweit- und drittletzten Commits in meinem Repo loszuwerden, während ich den obersten behalte. Ich stimme zu, dass keine der anderen Antworten zufriedenstellend sind.

    – MST

    17. Juni 2015 um 21:07 Uhr

  • @MST ja, ich hätte sagen sollen, keine der Optionen in der akzeptierten Antwort behandelt diese Frage, aber Sie haben absolut Recht – dieser Befehl scheint zu funktionieren

    – Chris

    10. Juli 2015 um 12:43 Uhr

  • Ich denke git reset --soft HEAD~1 ist genau das, was Sie brauchen. In einem solchen Fall machen Sie den Commit rückgängig und speichern Ihre Arbeit. reset --hard wird Commit vollständig entfernen.

    – sergpank

    18. Mai 2021 um 7:56 Uhr


  • Befehl: git log | Kopf -n 1 | git zurücksetzen

    – Amin Golmahalle

    1. Juni 2021 um 8:03 Uhr


Commits aus einem Branch in Git loschen
Greg Hewgill

Wenn Sie das Commit noch nicht irgendwo gepusht haben, können Sie es verwenden git rebase -i um diesen Commit zu entfernen. Finden Sie zuerst heraus, wie weit dieser Commit (ungefähr) zurückliegt. Dann mach:

git rebase -i HEAD~N

Die ~N bedeutet das letzte rebasieren N begeht (N muss zum Beispiel eine Zahl sein HEAD~10). Dann können Sie die Datei bearbeiten, die Git Ihnen präsentiert, um das anstößige Commit zu löschen. Beim Speichern dieser Datei schreibt Git dann alle folgenden Commits neu, als ob der von Ihnen gelöschte nicht existierte.

Das Git-Buch hat eine gute Abschnitt über die Umbasierung mit Bildern und Beispielen.

Seien Sie jedoch vorsichtig damit, denn wenn Sie etwas ändern, dass Sie verfügen über an anderer Stelle verschoben wird, ist ein anderer Ansatz erforderlich, es sei denn, Sie planen einen Force-Push.

  • Hinweis: Wenn Sie zufällig irgendwelche –no-ff-Merges in diesem letzten Batch von Commits haben, wird Rebase sie zerlegen 🙁 Dies wird unter -p on erwähnt diese Seite. Das Problem ist, wenn Sie -i durch -p ersetzen, erhalten Sie nicht mehr dieses Popup mit den Auswahlmöglichkeiten für “edit this commit, sqush that one”, etc etc. Kennt jemand die Lösung?

    – Bukow

    21. April 2013 um 0:20 Uhr

  • Was ist, wenn Sie es gedrückt haben? (nur ich benutze das Remote Repo)

    – Costa Michailidis

    7. Januar 2015 um 6:02 Uhr

  • @Costa können Sie verwenden push -f um den Push zu erzwingen und den Remote-Zweig durch Ihren lokalen zu ersetzen. Wenn es nur Ihr eigenes Remote-Repo ist, kein Problem. Der Ärger beginnt, wenn zwischenzeitlich jemand anderes abgeholt hat.

    – Greg Hewgill

    7. Januar 2015 um 6:16 Uhr

  • Ich habe eine Datendatei hinzugefügt und übergeben, die zu groß für GitHub war (ja, sie sollte wahrscheinlich sowieso nicht im Quellrepo sein; na ja). Als ich versuchte zu pushen, lehnte GitHub wegen der zu großen Datei ab. Alles, was ich tun wollte, war, diesen einen Commit rückgängig zu machen und gleichzeitig ein paar andere, nicht zusammenhängende Commits zu speichern, die folgten. Die git rebase -i HEAD~5 Befehl war exakt was ich brauchte, um diesen Commit vollständig aus meinem lokalen Repo zu entfernen! Danke!

    – Aldo

    24. Februar 2015 um 18:07 Uhr

  • @dumbledad: Mit rebase -iwerden die Änderungen, die dem gelöschten Commit entsprechen, nicht beibehalten.

    – Greg Hewgill

    10. Mai 2016 um 17:43 Uhr

  • thx, übrigens, wenn Sie auf Probleme stoßen (wie leere Commits), die Sie verwenden können git rebase --continue

    – realgt

    28. September 2012 um 15:43 Uhr


  • Sogar einfacher: git rebase -i HEAD~1

    – hmmm

    10. September 2013 um 21:12 Uhr


  • Wowzer. git rebase -i HEAD~1 hat das Repo wirklich sehr aufgeräumt! Es ist schwer zu sagen, was es genau getan hat, aber das Ganze sieht viel ordentlicher aus. Eigentlich ein bisschen alarmierend.

    – Karl Holz

    2. Dezember 2014 um 18:02 Uhr

  • Ich denke, es ist erwähnenswert, dass der Commit nicht ausgelöscht, sondern nur aus der Liste entfernt wird. Wenn Sie es vermasseln, können Sie den Commit mithilfe von zurückholen neu loggen.

    – Zaz

    29. April 2015 um 0:11 Uhr

  • Ist das Löschen der Zeile dasselbe wie d/drop?

    – Löwe

    25. Mai 2016 um 18:37 Uhr

Ich hänge diese Antwort an, weil ich nicht verstehe, warum jemand, der gerade versucht hat, Arbeit zu übergeben, all diese Arbeit wegen eines Fehlers bei der Verwendung von Git löschen möchte!

Wenn Sie Ihre Arbeit behalten und diesen Commit-Befehl einfach rückgängig machen möchten (den Sie vor dem Pushen in das Repo abgefangen haben):

git reset --soft HEAD~1

Verwenden Sie nicht –hard -Flag, es sei denn, Sie möchten Ihre laufende Arbeit seit dem letzten Commit zerstören.

  • Hier ist ein Beispiel dafür: Sie erledigen eine kleine Arbeit auf einem Entwicklungsserver, den Sie festschreiben. Dann stellt sich heraus, dass dieser Server keinen ausgehenden HTTPS-Zugriff hat, sodass Sie den Commit nirgendwo hinschieben können. Am einfachsten tun Sie einfach so, als wäre es nie passiert, und wiederholen Sie den Patch von Ihrem lokalen Computer aus.

    – Steve Bennett

    3. Januar 2013 um 4:32 Uhr

  • @KarthikBose es würde immer das Reflog geben. selbst nach git reset --hard HEAD~1 Ihr vorheriges letztes Commit wäre über Reflog verfügbar (bis Sie es ablaufen lassen); siehe auch hier: gitready.com/intermediate/2009/02/09/…

    – Kodierung

    6. Juni 2013 um 11:52 Uhr

  • Danke. Diese Antwort sollte höher eingestuft oder in die akzeptierte Antwort aufgenommen werden. Commit löschen != Commit rückgängig machen.

    – Alsciende

    5. März 2014 um 13:32 Uhr

  • @RandolphCarter: Sie verlieren jedoch immer noch alle nicht festgeschriebenen Änderungen.

    – nichts101

    1. September 2014 um 8:18 Uhr

  • @Rob, ein Beispiel ist, wenn Sie versehentlich eine Datei übergeben, die ein Geheimnis (z. B. ein Kennwort) enthält, das niemals in der Quellcodeverwaltung sein sollte. Der lokale Commit muss sein zerstörtnicht nur rückgängig gemacht, sodass es niemals auf den Server übertragen wird.

    – Bob Meyers

    15. November 2016 um 15:51 Uhr

Commits aus einem Branch in Git loschen
Will Ediger

Entfernen eines gesamten Commits

git rebase -p --onto SHA^ SHA

Ersetzen Sie natürlich “SHA” durch die Referenz, die Sie loswerden möchten. Das “^” in diesem Befehl ist wörtlich.

http://sethrobertson.github.io/GitFixUm/fixup.html#change_deep

  • Hier ist ein Beispiel dafür: Sie erledigen eine kleine Arbeit auf einem Entwicklungsserver, den Sie festschreiben. Dann stellt sich heraus, dass dieser Server keinen ausgehenden HTTPS-Zugriff hat, sodass Sie den Commit nirgendwo hinschieben können. Am einfachsten tun Sie einfach so, als wäre es nie passiert, und wiederholen Sie den Patch von Ihrem lokalen Computer aus.

    – Steve Bennett

    3. Januar 2013 um 4:32 Uhr

  • @KarthikBose es würde immer das Reflog geben. selbst nach git reset --hard HEAD~1 Ihr vorheriges letztes Commit wäre über Reflog verfügbar (bis Sie es ablaufen lassen); siehe auch hier: gitready.com/intermediate/2009/02/09/…

    – Kodierung

    6. Juni 2013 um 11:52 Uhr

  • Danke. Diese Antwort sollte höher eingestuft oder in die akzeptierte Antwort aufgenommen werden. Commit löschen != Commit rückgängig machen.

    – Alsciende

    5. März 2014 um 13:32 Uhr

  • @RandolphCarter: Sie verlieren jedoch immer noch alle nicht festgeschriebenen Änderungen.

    – nichts101

    1. September 2014 um 8:18 Uhr

  • @Rob, ein Beispiel ist, wenn Sie versehentlich eine Datei übergeben, die ein Geheimnis (z. B. ein Kennwort) enthält, das niemals in der Quellcodeverwaltung sein sollte. Der lokale Commit muss sein zerstörtnicht nur rückgängig gemacht, sodass es niemals auf den Server übertragen wird.

    – Bob Meyers

    15. November 2016 um 15:51 Uhr

Angenommen, wir möchten die Commits 2 und 4 aus dem Repo entfernen. (Je höher die Zahl ist, desto neuer ist der Commit; 0 ist der älteste Commit und 4 ist der neueste Commit)

commit 0 : b3d92c5
commit 1 : 2c6a45b
commit 2 : <any_hash>
commit 3 : 77b9b82
commit 4 : <any_hash>

Notiz: Sie müssen über Administratorrechte für das Repo verfügen da Sie verwenden --hard und -f.

  • git checkout b3d92c5 Überprüfen Sie den letzten verwendbaren Commit.
  • git checkout -b repair Erstellen Sie einen neuen Zweig, an dem Sie arbeiten möchten.
  • git cherry-pick 77b9b82 Commit 3 durchlaufen.
  • git cherry-pick 2c6a45b Commit 1 durchlaufen.
  • git checkout master Kassenmeister.
  • git reset --hard b3d92c5 Setzen Sie den Master auf den letzten verwendbaren Commit zurück.
  • git merge repair Führen Sie unseren neuen Zweig mit master zusammen.
  • git push -f origin master Schieben Sie den Master in das Remote-Repo.

  • letzter Schritt sein sollte git push -f origin master Es gibt keine Möglichkeit --hard

    – vivex

    15. Januar 2018 um 4:55 Uhr

  • ich schätze commit 0 ist älter als commit 1. Könnten Sie mir bitte sagen, warum Sie zuerst durchlaufen commit 3 (durch Cherry-Pick) und dann durch commit 1? Nach dem Auschecken von b3d92cd (commit 0) würde ich Rosinenpick erwarten commit 1dann commit 3. Danke.

    – Jarek C

    5. November 2018 um 11:51 Uhr

  • @JarekC Ich denke, das oberste Commit ist das neueste Commit hier, es sei denn, ich sehe etwas Falsches …

    – Jeff Huijsmans

    22. Januar 2019 um 15:06 Uhr

  • Das ist meistens richtig, aber irgendwie falsch. Ich habe diesen Prozess nur befolgt und musste ihn ein wenig optimieren. Klärung: commit 0 ist das neuste Commit, commit 4 ist die älteste. Beginnen Sie mit dem Auschecken commit 5, kurz vor dem Commit, das Sie nicht wollen. Dann cherry-pick commit 3dann cherry-pick commit 1dann tun Sie es für commit 0. Dann Master checken und auf zurücksetzen commit 5 und befolgen Sie die restlichen Schritte.

    – Joshua Swain

    7. Januar 2021 um 18:05 Uhr

  • Guter gründlicher und sicherer Ansatz. Die Verwaltung der Änderungen in einem separaten Zweig bedeutet, dass Sie sogar ein interaktives Rebasing auf dem durchführen können repair Commits verzweigen und kombinieren, bevor sie wieder zusammengeführt werden master. Der einzige Kommentar, den ich habe, ist, dass Sie die ersten beiden Schritte konsolidieren können: git checkout -b repair b3d92c5

    – Camslice

    7. Mai 2021 um 11:45 Uhr


986980cookie-checkCommits aus einem Branch in Git löschen

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy