Github Mist gebaut. Zu einem älteren Commit zurückkehren?

[felsi]

Hallo,

ich habe heute Morgen im Halbschlaf bei meinem Github Mist gebaut. Ich habe versucht zu commiten obwohl ich erst die aktuelle Version hätte pullen sollen. Jetzt habe ich es leider noch schlimmer gemacht, indem ich einen "merge" zugestimmt habe.

Ich würde das alles gerne einfach "ungeschehen" machen und zu einem Commit von gestern abend zurückkehren, so als ob nichts gewesen wäre.

Ist das irgendwie möglich?

Habe schon:
git revert --no-commit 123456..HEAD

probiert. Leider kommt dann der Error bzgl. dem Merge:
fatal: Commit <SHA1> is a merge but no -m option was given.

Bin leider kein Spezialist in Github. Wäre über jede Hilfe daher sehr dankbar.

 

[mschuebel]

Er weist dich ja schon darauf hin dass der Flag -m nicht gesetzt ist.
Mit diesem Flag lässt sich auch ein merge commit reverten.

 

[felsi]

Und was bedeutet das nun? Wie komme ich nun zu dem älteren Stand zurück?

 

[Key³]

git revert -m xxxxxxxxxxxxxxxxxxx

Wie die Meldung schon sagt, nimm noch "-m" mit auf dann sollte es gehen.

 

[horstle]

Ich würde es mal mit

git reset --hard 123456


versuchen. Habs aber noch nie in so einer Situation benutzt, bin mir also nicht ganz sicher obs funktioniert.

 

[felsi]

git revert -m xxxxxxxxxxxxxxxxxxx

Wie die Meldung schon sagt, nimm noch "-m" mit auf dann sollte es gehen.

Ja, das war es. Danke.
Leider ist er jetzt eine Version zu früh zurück, obwohl ich den richtigen Commit ausgewählt habe. Bisschen blöd, aber lieber so als anders.

 

[Ebrithil]

Du hast vermutlich den Commit genommen, auf den du wolltest. Der command geht aber nicht auf den Commit sondern revertet einen commit, deshalb bist du jetzt eine weiter vorne.

Im Zweifel immer erst die Doku lesen bevor man irgendwelche Commands ausführt!

 

[BLJ]

Wie von @horstle geschrieben besteht mit git reset --hard eine einfache Möglichkeit zu einem früheren Commit zurückzukehren. Dazu würdest du dann wohl aber auch noch ein history-rewrite (via force-push) benötigen.
Falls du alleine am repository arbeitest, funktioniert das gut. Andererseits, lieber meiden.

git revert ist hingegen die Umkehroperation zu einem bestimmten commit. D.h. du kannst (auch 2 Monate später ) noch die Änderungen von einem einzelnen commit rückgängig machen (nicht unbedingt praktikabel). Es benötigt kein history rewrite und ist damit in Teams praktikabler. Nachteil: das ungewollte commit (und das revert) bleiben Teil der history. Also nicht geeignet um Klartext-Passwörter aus dem Repo zu entfernen.

 

[Mihawk90]

Also nicht geeignet um Klartext-Passwörter aus dem Repo zu entfernen.

Entfernt werden die Commits auch bei reset --hard und push --force nicht. Die Commits sind weiterhin im Repository, nur eben außerhalb der "sichtbaren" Historie. Die sind zwar dann auf GitHub und in der normalen History nicht sichtbar, wenn man aber den Commit Hash kennt kann man den Commit auch auf GitHub anzeigen und jeder der das Repo clont kann ihn sowieso finden. Zumindest ist das mein letzter Stand, vielleicht hat sich das auch mal geändert.
Mal abgesehen davon, dass Passwörter (egal ob Klartext oder hashed) sowieso nichts im Code zu suchen haben gehören die grundsätzlich geändert wenn sowas auffällt.

edit:
Scheint wohl so als werden diese unreferenced Commits mittlerweile von der Garbage Collection bereinigt, inwiefern die auf GitHub greift weiß ich allerdings nicht.

 

[felsi]

Github ist schon eine gute Sache, aber gerade für Anfänger auch eine Wissenschaft für sich.

Gerade in solchen Fällen würde man sich als Anfänger wohl eine einfache UI wünschen, in der man z.B. ganz genau einen bestimmten Commit anklicken kann und zu diesem zurückkehren.

Mein Fehler war, dass ich gestern abend zuhause noch etwas geändert habe. Heute morgen habe ich dann an einem anderen Rechner Änderungen vorgenommen und diese commited. Zu diesem Zeitpunkt dreht das Git Plugin in Visual Studio Code schon durch.

Falls noch jemand einen Tipp hat, wie sich das beim nächsten Mal einfach fixen lässt, wäre ich echt dankbar. Mir ist das nämlich schon mal passiert.

 

[Mihawk90]

GitHub ist eben nur eine GUI für ein darunterliegendes System.

GitHub und Git haben an sich erstmal nichts miteinander zu tun. GitHub hostet Git repositories und bietet diverse Funktionen zu Zusammenarbeit, hat aber eben auch sonst nichts mit dem darunterliegenden System gemein.

GitHub hat übrigens in Ihrer Hilfe auch einen ausführlichen Artikel zum Thema:
https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository

Mein Fehler war, dass ich gestern abend zuhause noch etwas geändert habe. Heute morgen habe ich dann an einem anderen Rechner Änderungen vorgenommen und diese commited. Zu diesem Zeitpunkt dreht das Git Plugin in Visual Studio Code schon durch.

Ich benutze VSC nicht aber das versteh ich nicht ganz. Das würde ja bedeuten der Zweitrechner sieht auch das Repo auf deinem Heim-PC (denn warum sollte es sonst "durchdrehen"?).
Wenn das der Fall ist kannst du doch einfach von deinem Repo am Heim-PC pullen und dann commiten, bzw. wenn schon commitet wurde einen merge oder rebase machen.

 

[felsi]

Hm, keine Ahnung. Also ich habe das Repo am Heim-PC und im Büro eingebunden.
Wenn ich zuhause etwas commite, muss ich immer erst am Arbeits-PC pullen, um die aktuellen Daten zu haben. Soweit so richtig, denke ich?!

Wenn ich vor dem Pullen aber Änderungen vornehme und "aus Versehen" commite, sagt VSC, dass der Working Tree nicht sauber ist, oder so etwas in der Art. Ich habe dann einfach die Änderungen verworfen, aber irgendwie kam es dann trotzdem zu dem Schlammassel.

 

[Mihawk90]

Wenn ich zuhause etwas commite, muss ich immer erst am Arbeits-PC pullen, um die aktuellen Daten zu haben. Soweit so richtig, denke ich?!

Das kommt darauf an wie du es eingerichtet hast.
grundsätzlich hast du ja 3 Repos:
1. Heim-PC
2. Arbeits-PC
3. GitHub

Wenn du sowohl am Heim-PC und am Arbeits-PC jeweils nur GitHub eingerichtet hast musst du jeweils vorher auf GitHub pushen um die Änderungen dann auf den Heim- oder Arbeits-PC pullen zu können.

Sofern du es so eingerichtet hast, dass du von deinem Heim-PC auch deinen Arbeits-PC sehen kannst (oder andersrum), kannst du auch direkt von diesen Repos pullen.

Wenn sich Heim-PC und Arbeits-PC nicht gegenseitig sehen können verstehe ich nicht wie es zu Problemen kommen soll, da die von den Änderungen gegenseitig ja gar nichts wissen ohne sich zu synchronisieren (eben direkt, oder über einen push/pull auf GitHub).

Ergänzung (16. März 2020)

Wenn ich vor dem Pullen aber Änderungen vornehme und "aus Versehen" commite, sagt VSC, dass der Working Tree nicht sauber ist, oder so etwas in der Art. Ich habe dann einfach die Änderungen verworfen, aber irgendwie kam es dann trotzdem zu dem Schlammassel.

Wenn der Working-Tree nicht sauber ist musst du die Änderungen nicht zwingend verwerfen. Du kannst beim Pull entweder einen rebase machen um deine Änderungen auf die neuen Commits anzuwenden oder vor dem Pull einen Stash machen. Damit werden die aktuellen Änderungen zwischengespeichert und aus dem Working Tree entfernt. Man kann dann sauber pullen und anschließend den Stash wieder anwenden um die Änderungen wieder einzupflegen. Beides hat seine Vor- und Nachteile, aber verwerfen muss man die Änderungen nie.

Wenn du vor dem Pullen commitest ist auch nichts verloren solange du nicht pushst (und selbst dann gibt es noch Möglichkeiten, ist nur ungünstig wenn mehrere am Remote (GitHub) Repo arbeiten).
Mit einem reset --hard kannst du im Tree zurückgehen und dann neu pullen. Dabei gehen alle Commits ab dem eingegebenen Commit verloren. Man sollte daher die im Commit geänderten Dateien sichern, weil diese beim reset ebenfalls verloren gehen. Nach dem Pull kann man die Dateien dann wieder in den Working Tree kopieren und weiterarbeiten.

 

[horstle]

Ich schätze er hat die Änderungen am Heim-PC schon auf Github gepusht, aber bei der Arbeit nicht gepullt, bevor er weitergemacht hat.

git pull ist ja im Prinzip dasselbe wie git fetch und danach git merge. Wenn du aber lokal nicht mehr aktuell bist, dann aber einen neuen Commit erstellst, würde ich git rebase empfehlen.
Also commitest du lokale Änderungen, holst mit git fetch den aktuellen Stand von origin und machst dann git rebase origin/master, sofern dein Branch master heißt. Falls der rebase nicht automatisch klappt, werden die betroffenen Stellen dann im Quellcode markiert (mit <<<<<, ====== und >>>>>), das musst du manuell korrigieren, adden und mit git rebase --continue weitermachen.

 

[Mihawk90]

Ich schätze er hat die Änderungen am Heim-PC schon auf Github gepusht, aber bei der Arbeit nicht gepullt, bevor er weitergemacht hat.

Ja vermute ich auch.

Ich denke hier liegt auch ein grundlegendes Verständnisproblem vor was ein git commit und ein git push ist. Nur um es nochmal deutlich zu machen: git commit legt in deinem lokalen Repo einen neuen Commit an. Dieser ist damit nicht veröffentlicht (d.h.: nicht auf GitHub). Ein git push dagegen sendet alle lokalen Commits, welche noch nicht auf dem Remote-Repo (GitHub) sind dorthin.
Um einen git push auf ein Repo zu machen muss das dazu auch eingerichtet sein. Ein git pull dagegen kann von einem beliebigen Repo erfolgen, solange man es mal irgendwann eingerichtet hat. Denn damit zieht man sich dort vorliegende Commits einfach selbst, ohne zutun des anderen Repos.

 

[felsi]

Ja, ich pushe immer am Ende des Tages, um dann eben am nächsten Tag auf dem jeweils anderen Rechner durch pullen wieder den aktuellen Stand zu haben. Anders ergibt es ja keinen Sinn, oder?

Zum commiten: Was passiert, wenn ich an einem Rechner meine Änderungen commite und nicht pushe? Und dann am anderen Rechner auch Änderungen commite? Wie werden diese ganzen Änderungen dann zusammengefasst?

 

[Mihawk90]

Anders ergibt es ja keinen Sinn, oder?

Schon richtig so.
Commit PC1 -> Push Remote -> Pull PC2

Was passiert, wenn ich an einem Rechner meine Änderungen commite und nicht pushe? Und dann am anderen Rechner auch Änderungen commite? Wie werden diese ganzen Änderungen dann zusammengefasst?

Automatisch? Gar nicht. Ohne Push sind die Änderungen lokal und bleiben es.
Eine Zusammenführung musst du dann im Rahmen eines rebase oder merge machen, wenn du Änderungen pullst.
Beispiel:
Commit am Heim-PC - ohne push
Commit am Arbeits-PC - mit push
Der Arbeits-PC sieht natürlich die Änderungen vom Heim-PC nicht, weil die nirgendwo veröffentlich sind, sondern lokal auf dem Heim-PC.

Wenn du wieder zuhause bist kannst du dann die Änderungen, welche du am Arbeits-PC gemacht (und gepusht) hast, vom Remote pullen. Dabei hast du dann die Option entweder einen Rebase zu machen oder einen Merge-Commit zu erzeugen.
Auf beide Arten werden die Änderungen zusammengeführt. Beide haben wieder ihre Vor- und Nachteile, aber der Effekt ist am Ende der gleiche (zumindest was den Code angeht, die Git History sieht aber anders aus).
Danach hast du die Option wieder auf den Remote zu pushen, oder eben nicht. Wenn du pushst kannst du den Merge dann direkt am Arbeits-PC pullen und beide sind gleich auf. Wenn du nicht pushst weiß der Arbeits-PC wiederum nichts vom Merge und es geht wieder von vorn los.

 

[BLJ]

...
Mal abgesehen davon, dass Passwörter (egal ob Klartext oder hashed) sowieso nichts im Code zu suchen haben gehören die grundsätzlich geändert wenn sowas auffällt.
...

Da hast du natürlich volkommen recht - einmal versehentlich veröffentlichte Keys muss man ASAP ändern.

Da man auf das GitHub Repo nicht direkt direkt Zugriff hat, kann man auch kein GC forcieren, d.h. die commits verschwinden nach Ermessen von GitHub.

 

[ayngush]

Kann auch dringend die Extension "Git Graph" für VSCode empfehlen. Aber bitte auch darin einlesen, da kann man nämlich durch ein paar "Klicks" ganz schön randalieren

 

[new Account()]

Gerade in solchen Fällen würde man sich als Anfänger wohl eine einfache UI wünschen, in der man z.B. ganz genau einen bestimmten Commit anklicken kann und zu diesem zurückkehren.

Gibt doch genügend UIs für Git - z.B. GitKraken:
https://www.netways.de/blog/2018/11/08/gitkraken-der-nahezu-perfekte-git-client/

Benutze ich selbst als Nichtanfänger.