git: revert immer mit Fehlern

[hwmuffel]

Hallo zusammen,
ich hoffe es gibt hier einige Git-Provis.
Werde noch zum Hirsch. Zuerst hat revert in VSC immer Fehler gegeben dann habe ich es in einem neuen Verzeichnis und ganz händisch in der Konsole versucht aber es bleibt beim Fehler.

Ordnerinhalt:
.git
hello.py

Aktionen:
- 4 kleine Änderungen die jeweils mit git add . und git commit -m ins R. transportiert wurden
Dann möchte ich mit revert zurück auf einen älteren Commit und bekomme immer folgende Fehlermeldung:

PS C:\hp\vsc_py> git revert b23ba755ee6b898c32c45bae8e9be457e6c6a3b8
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
error: could not revert b23ba75... zweiter commit V2
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Wo ratet ihr mir den Fehler zu suchen? Bin motivierter Anfänger mit Git :-)

Danke

 

[umask007]

Warscheinlich willst du einen Commit rückgängig machen,
der Zeilen betrifft, die in einem späteren Commit wieder geändert wurden,
daher der Konflikt.
Also wenn du alles rückgängig machen willst, versuch mal
git revert b23ba755ee6b898c32c45bae8e9be457e6c6a3b8..HEAD
oder git reset b23ba755ee6b898c32c45bae8e9be457e6c6a3b8
Letzeres generiert keinen neuen Commit,
sondern setzt das Repo zurück, revert hingegen macht einen oder mehrere Commits
rückgängig. Warscheinlich ist reset das was du brauchst (du wolltest auf einen älteren Commit zurück, oder?)

 

[benneq]

Ein paar mehr Details wären hilfreich bzw. ein minimal reproducible example (MRE). Am Besten mit einer einfachen Textdatei mit 3-4 Zeilen Inhalt, die du veränderst.

Grundsätzlich kann so ein Revert aber schon zu Konflikten führen, weil das Ergebnis nicht immer eindeutig ist.

Nehmen wir statt Git mal eine Leinwand. Zu Beginn ist sie komplett weiß, danach malst du alles blau, und danach malst du die erste Hälfte grün, danach die zweite Hälfte rot, und danach alles schwarz.
Also ist sie jetzt (aktueller Stand) komplett schwarz. Was sollte deiner Meinung nach passieren, wenn du den dritten Schritt (Hälfte grün anmalen) rückgängig machst? Vermutlich nichts, alles soll so bleiben wie es ist. Aber wozu dann reverten? Oder sollte sie danach wieder komplett blau sein? Oder halb rot, halb blau? Also so ganz eindeutig ist die Lage wohl doch nicht.

Das lässt sich mit Git und Textdateien natürlich noch beliebig komplexer ausführen und für noch mehr Ungewissheiten sorgen.

 

[68000]

Mal eine Doku zu revert durchgelesen?
https://www.atlassian.com/de/git/tutorials/undoing-changes/git-revert

 

[Bitopium]

Dann möchte ich mit revert zurück auf einen älteren Commit

Wenn du wirklich das machen willst was du hier beschreibst dann ist revert das Falsche.
Dafür verwendet man einen checkout:

git checkout b23ba755ee6b898c32c45bae8e9be457e6c6a3b8

Dann landest du in einem detached HEAD state und kannst dir den Stand von dem Commit anschauen. Möchtest du darauf dann nochmal Änderungen machen solltest du von dort einen neuen branch mit git checkout -b <BRANCH> erzeugen

 

[hwmuffel]

Wenn du wirklich das machen willst was du hier beschreibst dann ist revert das Falsche.
Dafür verwendet man einen checkout:

git checkout b23ba755ee6b898c32c45bae8e9be457e6c6a3b8

Dann landest du in einem detached HEAD state und kannst dir den Stand von dem Commit anschauen. Möchtest du darauf dann nochmal Änderungen machen solltest du von dort einen neuen branch mit git checkout -b <BRANCH> erzeugen

Hallo,
ahh, super! Funktioniert! Wenn ich mit checkout von Version 4 auf 2 zurück gehe, geht Version 3 und 4 aber verloren? Mit git switch - kann man den Checkout dann aber wieder rückgängig machen.

Die anderen Hilfetipps mit revert haben nicht geklappt.

Kein leichtes Thema finde ich, und bevor man seine Programme mit Git total zerschnipselt hat sollte man sich gut auskennen.



Danke nochmals!

 

[Bitopium]

Wenn ich mit checkout von Version 4 auf 2 zurück gehe

Nein erstmal geht nichts verloren.

Sagen wir mal du hast 4 commits auf deinem Branch namens master und hast Commit 4 ausgecheckt (dein Worktree HEAD zeigt somit auf master, Commit 4, also das was du im Explorer siehst):

             HEAD
             master
o---o---o---o
1   2   3   4

Und jetzt sagen wir mal dein Ziel ist es nochmal die Version 2 anzuschauen, dann könntest du ein git checkout 2 machen und hättest dann folgenden lokalen Repository Zustand:

    HEAD    
    |       master
o---o---o---o
1   2   3   4

Du hast also Commit 2 ausgecheckt und kannst dir den Zustand anschauen. Version 3 und 4 existieren aber trotzdem noch sowie der Branch master und du kannst jederzeit wieder dort zurück. Möchtest du wieder auf den Commit vom master kannst du einfach ein git checkout master ausführen.

Möchtest du von Version 2 andere Änderungen machen müsstest du von 2 stattdessen einen neuen Branch/Zweig aufmachen (git checkout -b neu oder git switch -c neu). Committest du dort Änderungen (commit 5) schaut es dann wie folgt aus:

           5
      + ---o neu
     /    
o---o---o---o master
1   2   3   4

Ab hier wird dann Merging relevant weil man sich ab hier Gedanken machen muss ob man neu und master in der Zukunft wieder vereinigen möchte.

Möchtest du dauerhaft zu Commit 2 zurück und Commit 3+4 "löschen" könntest du ein git checkout master gefolgt von einem git reset --hard 2 ausführen womit dein Graph wie folgt ausschaut:

    HEAD    
    master
o---o
1   2

Es gibt wenige Befehle die das Potential haben Arbeit zu verlieren, git reset ist einer davon.
Solange du allerdings deine lokalen Änderungen nicht auf das Remote Repository pushst, ist das auch nicht so kritisch und selbst lokal noch wiederherstellbar weil die Commits noch im reflog sind, das führt jetzt aber zu weit.... Wirklich Arbeit verlieren kann man z.B. mit der Kombination aus git reset zusammen mit git push --force

 

[hwmuffel]

Möchtest du wieder auf den Commit vom master kannst du einfach ein git checkout master ausführen.

... hier sollte es wahrscheinlich heißen: "Möchtest du wieder auf den letzten Commit vom master..." ??

Danke, super Beschreibung! Wurde ausgedruckt und liegt mal die nächste Zeit am Rechner parat.

 

[Bitopium]

auf den letzten Commit vom master

Öhm ja, oder etwas genauer: Auf den Commit auf den master gerade zeigt ;-)
Aber ich glaube du hast es verstanden, darum gehts :-)

 

[hwmuffel]

Ja, habe jetzt alles verstanden und klappt auch in der Praxis .... mit einer komischen Ausnahme jetzt:
Ich füge eine weitere Datei neu hinzu und mache einen add + commit. Wenn ich nun einen checkout auf eine ältere Version oder anderen Branch mache, dann wird diese neu hinzugefügte Datei gelöscht mitsamt der neuen Version (arbeite mit Git graph in VSC).
Kann mir das einfach nicht erklären!

 

[Bitopium]

Ja natürlich wird sie dann gelöscht wenn die Datei im älteren Commit den du auscheckst noch nicht da war?

Was erwartest du denn was passiert wenn du heute eine Datei hinzufügst und dir dann eine Version von gestern anschaust?

Stell dir das so vor ohne git: Du hast einen Ordner in dem liegen deine Source Dateien. Wenn du für heute fertig bist dann benennst du den Ordner V1. Morgen möchtest du weiter arbeiten und machst eine Kopie von dem V1 Ordner, nennst ihn V2 und fügst dort eine neue Datei hinzu. Jetzt würdest du gerne die Version von gestern anschauen also machst du den Ordner V1 auf. In dem Ordner ist dann natürlich nicht die neue Datei von V2 drin.
So ähnlich läuft es mit Commits 😊 vielleicht hilft ja die Analogie

 

[hwmuffel]

Ok, ich komme wahrscheinlich nur nicht mit der Arbeit in git graph zurecht. Das muss ich mir nochmals genau ansehen. Über die Shell klappt es so wie von dir beschrieben. Die Datei taucht dann auch wieder auf wenn ich auf die neuere Version gehe.