Git - SourceTree - alten Quelltext auschecken

[Sherlock]

Das wichtigste zuerst: Wenn es committed ist und sogar auf den Server gepusht wurde, dann kann nichts kaputt gehen.
SourceTree sagt in der englischen Version zu dem gewünschten Schritt (eine ältere Revision benutzen) "Update to...". Das ist meiner Meinung nach eine der Grundfunktionen. Gratuliere, daß Ihr das bisher nicht gebraucht habt, spricht für Euren Code.

Ausgehend von hier https://confluence.atlassian.com/get...ith-sourcetree empfehle ich (nochmal) einen kurzen bis mittel langen Blick in die wirklich gute Doku von SourceTree zu werfen.

Sherlock

[TigerLilly]

Und: Leg ein Testprojekt an + probier an dem die Funktionen aus. Dann kannst du auch mal was zerstören (ja, das geht auch mit einem VCS) + du musst dich nicht erschießen. :- )

[Stevie]

git bisect

[freimatz]

Zitat von Sherlock:

Das wichtigste zuerst: Wenn es committed ist und sogar auf den Server gepusht wurde, dann kann nichts kaputt gehen.

Doch natürlich. Gerade mit dem vorgeschlagenen reset - wenn es dem git reset entspricht.
Wenn ich z.B. den branch "master" habe und 10 commits und der master zeigt auf den letzten commit also #10. Wenn man dann einen reset auf commit #5 macht, dann zeigt der master auf #5. Commit #6 bis #10 sind dann weg. Zuerst nur optisch, wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log sind sie nach dem nächsten pack (git gc) wirklich weg.

Ich schlage vor auf den alten Stand einen neuen branch zu erzeugen und diesen auszuchecken.

[Aviator]

Zitat von freimatz:

Ich schlage vor auf den alten Stand einen neuen branch zu erzeugen und diesen auszuchecken.

That's the way to go. Zumindest habe ich beim Lernen von GIT vor einigen Jahren es immer wieder so gelesen. Und es ist m.M.n. auch die sicherste Variante. Und wenn ich sehe, dass ich auf den falschen Commit zurück gegangen bin, dann kann ich den Branch einfach löschen und den anderen Commit auschecken. Mit reset sollte man nur arbeiten, wenn man Änderungen rückgängig machen will.

[Stevie]

Zitat von freimatz:

Zuerst nur optisch, wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log sind sie nach dem nächsten pack (git gc) wirklich weg.

Auch wenn ich zustimme, nen Branch oder nen Tag vom aktuellen Stand anzulegen, stimmt das nicht.
Das ref log hat eine Verfallsdauer von 90 Tagen als Default. Da haut auch nen standard git gc nix weg von.
Dafür musst schon explizit nen git reflog expire now aufrufen.

Siehe https://git-scm.com/docs/git-gc

[Sherlock]

Also wenn git es tatsächlich erlaubt, mit simplen Befehlen das Repository derart zu zerstören, daß Commits auch auf dem Server entfernt werden können, dann bin ich froh bei Mercurial geblieben zu sein. Wollte zwar wegen meinem lokalen BitBucket auf Git umsteigen, aber mit hg-git komme ich dann weiterhin bestens zurecht.

Bei der Entscheidungsfindung hg oder git kam mir immer wieder mal das Grausen, was die git-Entwickler so für notwendig hielten...

Und was ist eigentlich dieses "auschecken"? Hg und git brauchen sowas doch gar nicht. Man Updatet auf einen Stand und wenn man fertig ist, wird gemerged und commite, oder meinetwegen ein Pull-Request geschickt.

Sherlock

[Stevie]

Zitat von Sherlock:

Also wenn git es tatsächlich erlaubt, mit simplen Befehlen das Repository derart zu zerstören, daß Commits auch auf dem Server entfernt werden können, dann bin ich froh bei Mercurial geblieben zu sein. Wollte zwar wegen meinem lokalen BitBucket auf Git umsteigen, aber mit hg-git komme ich dann weiterhin bestens zurecht.

Bei der Entscheidungsfindung hg oder git kam mir immer wieder mal das Grausen, was die git-Entwickler so für notwendig hielten...

Und was ist eigentlich dieses "auschecken"? Hg und git brauchen sowas doch gar nicht. Man Updatet auf einen Stand und wenn man fertig ist, wird gemerged und commite, oder meinetwegen ein Pull-Request geschickt.

Oh bitte hör auf, solchen Unsinn zu glauben oder weiter zu verbreiten. Es ist mit enormen Hürden verbunden, Commits auf dem Server zu überschreiben. Erstens sind die lokal immer noch vorhanden und werden nicht einfach vom nächsten git gc gelöscht und außerdem muss man für eine deratige Aktion bewusst einen force push machen - und je nach git Verwaltung kann man das verbieten.

Da ist es einfacher eine Datei mit Shift+Delete zu vernichten, so dass du irgendwelche Disk Tools bemühen musst, um sie wieder herzustellen.
git checkout ist nix anderes als auf einen bestimmten Branch zu wechseln - ich bin sicher, das kann man in Mercurial auch.

[Sherlock]

Ich hab doch nicht damit angefangen. Ich hatte meinen Einstieg in diesen Thread eingeleitet mit "es kann nichts kaputt gehen". Freilich unterstelle ich mal, die Abwesenheit von Mutwilligkeit. Dann kamen entsetzte "Doch man bekommt alles ganz einfach kaputt" Einwände.

OK, ich wußte nicht, daß "hg update" von git checkout genannt wird. Halte ich persönlich für kontraproduktiv, weil man einen SVN-Begriff zweckentfremdet, aber mir egal.

Ich halt mich jetzt lieber raus. Bin ohnehin nur indirekter git Anwender.

Sherlock

[freimatz]

Zitat von Stevie:

Zitat von freimatz:

Zuerst nur optisch, wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log sind sie nach dem nächsten pack (git gc) wirklich weg.

Auch wenn ich zustimme, nen Branch oder nen Tag vom aktuellen Stand anzulegen, stimmt das nicht.
Das ref log hat eine Verfallsdauer von 90 Tagen als Default. Da haut auch nen standard git gc nix weg von.

Ich stimme dir in allem zu, ausser in "stimmt das nicht". Ich schrieb ja "wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log" (da fehte dann von mir ein Komma).

Das mit dem "und sogar auf den Server gepusht" von Sherlock habe ich übersehen. Sorry. Dann kann man nur lokal was kaputt machen und im schlimmsten Fall wieder auf einen master Stand. Ausnahme dann wie Stevie schrieb dann mit Böswilligkeit (oder absichtlicher Gutwilligkeit). Hm, wenn ich so überlege habe ich das selber schon öfters gemacht: auf einem Branch; etliche commits; gepushed; reset auf einem älteren Stand; (push geht dann nicht); branch remote gelöscht, neuer push. (In disen Fällen war der branch nur von mir genutzt)

Die Entscheidungsfindung hg oder git hatten wir auch mal und ich bin froh im nachhinein, dass wir zu git gewechselt haben.