Code in Visual Studio durch Github "Abrufen" überschrieben

[DeepComputer]

Hallo,

hab gerade ziemlich viel Arbeit verloren.
Hab unabsichtlich im Visual Studio GitHub auf Abrufen gedrückt und das hat meinen Code wieder auf einen alten Stand zurückgesetzt.
Ich hab den alten Code gespeichert - allerdings find ich den nicht. Der Visual Studio BackUp Ordner ist einfach leer, obwohl aktiviert.
Auf Rückgängig klicken hat auch nichts geholfen. Es hat einfach meine Datei überschrieben.
Ich hab Visual Studio ohne speichern geschlossen aber die Datei wurde einfach überschrieben.

Bitte Hilfe!

 

[Tornhoof]

Wenn du in VS pull von git machst werden Dateien die lokal geändert sind nicht überschrieben. Sicher dass du nicht den Branch gewechselt hast? Selbst dann sollte VS eine Meldung bringen, dass du geänderte Dateien sichern musst (kann man aber deaktivieren).

Ansonsten sicherstellen, dass du wirklich den richtigen Backup Ordner prüfst.
https://docs.microsoft.com/de-de/vi...r-environment-options-dialog-box?view=vs-2019

Der Ordner hat sich nämlich zwischenzeitlich mehrmals geändert

 

[DeepComputer]

Ich habe die Datei mit Strg+s gespeichert. Ich habe sie nicht hoch geladen. Ich hab aber offensichtlich nur "alten code" runtergeladen, der die Datei automatisch im Inhalt überschrieben hat.
Ich mein - was soll das bitte? Das ist ja das absolut dümmste was dir Git bescherren kann!!!

 

[Yuuri]

Das ist ja das absolut dümmste was dir Git bescherren kann!!!

Jetz komm mal runter und hör auf andere für dein Handeln verantwortlich zu machen.

VSCode überschreibt nichts "einfach so" und git erst recht nicht. git warnt dich quasi vor jeder Operation und bricht sogar strikt ab, wenn was nicht passt wie es soll.

Also: Was hast du genau gemacht? "von Github abrufen" taugt genau nichts. Fetch? Merge? Pull? Was? Wenn du nen Forced Checkout machst, ist das natürlich dein eigenes Pech. Was sagt der Reflog?

 

[DeepComputer]

Ja, "komm mal runter."
Glaubst du mich freuts gerade, dass ich 5 Stunden Code verloren hab?
Irgendwo muss man sich ja Luft holen... und euch mach ich sowieso nicht verantwortlich.
Ich weiß es, dass ich selber schuld bin weil ich dieses Github nicht durchblicke.

 

[Ragemoody]

Die entscheidende Frage ist, ob du zwischendurch commited oder gestashed hast, oder nicht.

 

[DeepComputer]

Ok, ich habs wieder! <3 es war zum Glück "gestashed" - was ich gerade am Screenshot gesehen hab! freu und Erleichterung

 

[Tornhoof]

Du solltest ggf mal etwas über den git Workflow lesen und verstehen.

Außerdem mal deine git Einstellungen prüfen, nicht dass du pull.rebase und rebase.autostash an hast.

 

[DeepComputer]

Ich kenn mich mit Git leider überhaupt nicht aus. Werde mich daran erst noch gewöhnen müssen.
Ich verstehe die Begriffe nicht.
Könnt ihr mir bitte nur noch helfen, dass wieder hinzukriegen?

 

[Yuuri]

Ich kenn mich mit Git leider überhaupt nicht aus. Werde mich daran erst noch gewöhnen müssen.
Ich verstehe die Begriffe nicht.

Dann fang am besten erstmal auf der Kommandozeile an, damit du die Operationen kennenlernst und nicht der ganzen "Magie" einer jeden IDEs ausgeliefert bist. Jeden den ich kenne, der git durch eine IDE "gelernt" hat, hat überhaupt keine Ahnung davon. Und das ist nicht gut (wie du ja selbst grad siehst).

Könnt ihr mir bitte nur noch helfen, dass wieder hinzukriegen?

Das bedeutet dass dein Stash nicht mehr konfliktfrei auf den Commit angewendet werden kann. Sieh dir also an, wie man in git nen Konflikt löst. Bei Merge conflicts kann man allerdings die IDE gut und gern nutzen, da das auf der Konsole der reinste Krampf ist.

 

[DeepComputer]

Ja, es wird schon kommen mit der Zeit.
Für heute geh ich mal beruhigt schlafen das hätte mir sonst keine Ruhe gelassen

 

[PHuV]

Nur mal so, eine Sicherheitskopie hat noch nirgends geschadet.

 

[madmax2010]

Ok, ich habs wieder! <3 es war zum Glück "gestashed" - was ich gerade am Screenshot gesehen hab! freu und Erleichterung

und jetzt einmal laut Danke git.

Es ist beinahe unmöglich in git etwas unwiederbringlich kaputt zu machen.

Sehr mutwillig kann man X branches so verweben, dass es am Ende irgendwie der gordische Knoten ist.. aber auf bekommt man selbst den ohne schwert.

 

[Airbag]

Nur mal so, eine Sicherheitskopie hat noch nirgends geschadet.

Häufiges Pushen in einen Remotebranch ist da sinnvoller. Selbst wenn man einen hard-reset macht, ist dann nicht so viel verloren. Anschließend bei fertiger Entwicklung merge in den Zielbranch ggf. per Request.

 

[Wasserhuhn]

Mir fehlte anfangs auch das Vertrauen und habe zusätzlich händisch Sicherungen gemacht. Häufig mache ich das immernoch.

 

[DeepComputer]

so mach ich das jetzt auch.

 

[SheepShaver]

Vertrauen in was? In euch selbst oder in git? Wie oben schon erwähnt geht in git nichts verloren.

 

[Wasserhuhn]

In mich und VS.
VS hat mir schon mehrmals Probleme bereitet, die eine Neuinstallation erforderten.

 

[Elbrathil]

Ich arbeite schon eine Weile mit Git, als Profi würde ich mich aber nicht bezeichnen. Den Tipp von Yuuri finde ich aber sehr gut: Verwende nicht die Oberfläche von VS, sondern die Kommandozeile. Mit den GUI-Tools habe ich mich auch schon ein paarmal in unerwartete Situationen gebracht. Wenn du die git-Befehle einzeln und bewusst per Kommandozeile erteilst, passiert sowas nicht so schnell. Die Rückmeldungen von git auf der Kommandozeile sind sehr gut. Es gibt auch recht gute Dokumentationen zu den Befehlen, die wohl seinesgleichen in anderen Softwareprojekten suchen. Mag also erst vielleicht etwas widersinnig erscheinen, auf die Kommandozeile zu gehen, wenn man sich mit einem Tool nicht so gut auskennt, ich fands aber tatsächlich einfacher.

 

[Dalek]

Es ist beinahe unmöglich in git etwas unwiederbringlich kaputt zu machen.

Sehr mutwillig kann man X branches so verweben, dass es am Ende irgendwie der gordische Knoten ist.. aber auf bekommt man selbst den ohne schwert.

Daten die committed waren zu verlieren ist tatsächlich recht schwer. Aber wenn man sich mit Git nicht gut auskennt kann man schon durchaus in Situation kommen in denen man die Daten einfach nicht wiederfindet. Natürlich sind sie noch da, aber das hilft einem in der Situation halt auch nicht. Ich hab mal einen Commit mit git reflog suchen müssen, ich hatte wohl aus Versehen im "detached HEAD" Modus committed. Natürlich geht das wenn man weiß das diese Möglichkeit existiert, aber für eine Git Anfänger ist das praktisch das gleiche als ob die Daten komplett weg wären.

Ich würde aber auch sehr stark empfehlen die Kommandozeile zu benutzen. Ich hab erst angefangen die GUI zu benutzen nachdem ich verstanden habe was genau die GUI am Ende macht. Das Problem ist das die GUIs versuchen ein bißchen was von der Komplexität von Git zu verstecken, und am Ende scheitern sie eigentlich immer damit. Wenn in der GUI etwas nicht funktioniert hat man keine Chance das zu beheben wenn man die Kommandozeile nicht kennt und versteht wie git funktioniert.

Die einfachste Version git zu benutzen ist eigentlich unproblematisch, wenn man nur einen branch hat und einfach nur dort commits macht. Das ist auf der Kommandozeile mit 2-3 Befehlen zu machen, und dann ist man auch sicher das da nichts anderes passiert. Und für die Fälle in denen man noch alle Daten hat, aber git in einem Zustand ist den man nicht versteht gibt es immer noch dieses XKCD Comic.

Eine ganz wichtige Regel noch, niemals einen Befehl mit "--force" ausführen wenn du nicht genau verstehst was das macht. Das ist eine der Varianten wirklich Daten zu verlieren mit git.