Git - SourceTree - alten Quelltext auschecken

[Incocnito]

Hallo Zusammen,

ich habe privat die Quellen von mir und einem gutem Kollegen per git & SourceTree verwaltet
und habe nun einen Bug, der zwar nachvollziehbar ist, aber an einer Stelle passiert,
wo es augenscheinlich keinen Sinn ergibt. Ich denke, dass ich irgendwo anderes
was kaputt gemacht habe und das erst später Auswirkungen zeigt.
Nun denke ich, dass ich doch einfach mal die Version des Quelltextes zurück stellen kann
(auf die Version von Anno dazumal) und mal schauen, ab welcher Änderung das nicht mehr
geht / der Fehler auftritt.
Nun nutzen wir allerdings von Git/SourceTree gerade mal einen Bruchteil der Funktionen.
Wir haben beide kaum eine Ahnung, wie das alles funktioniert und bisher ist das auch
mehr so ein "das was wir brauchen kann es, mehr interessiert uns nicht".
Daher wollte ich hier mal fragen, was genau ich machen muss, bevor ich da was kaputt mache.
Ich möchte auf meinem Rechner die Quellen auf eine ältere Version zurück stellen ohne
die Quellen auf dem Server (im Git-Repository) oder die meines Kollegen zu verändern.
Ich denke (gefährliches Halbwissen) die richtige Funktion wäre "auschecken".
Leider verwenden die Anleitungen, die ich so spontan gefunden habe Fachbegriffe,
die wohl ein gewisses Basiswissen benötigen, was wir beide nicht haben.

Bei dieser Gelegenheit vielleicht mal gefragt: Wisst ihr eine Stelle,
wo man mit Null Vorwissen eine kinderleichte Erklärung für Git & SourceTree bekommt?
Wobei: Ich wollte nun weniger auf der Konsole mit git rumwerkeln, sondern wirklich nur wie
das Ganze in SourceTree funktioniert. Was machen die Funktionen? Einfache Beispiele.
Was passiert warum?

Vielen Dank schonmal für die Mühe! Ich weiß, das Ganze klingt etwas nach
"bevor ich mir selbst Mühe gebe frage ich einfach", aber ich bin für die
bisher gefundenen Anleitungen einfach zu doof und gerade in diesem Fall zu unsicher.

[Edit: Ich sehe gerade: das hätte nach "Sprachen und Entwicklungsumgebungen" -> "Andere Werkzeuge" gemusst! Sorry!]

Liebe Grüße
Incocnito

[DP-Maintenance]

Dieses Thema wurde am "11. Feb 2020, 17:34 Uhr" von "Luckie" aus dem Forum "Programmieren allgemein" in das Forum "Sonstige Werkzeuge" verschoben.

[himitsu]

Reset müsste die Funktion sein, um zu einer bestimmten Revision zurückzugehn. (im SVN nennt die sich netter Weise "update to revision")

Local Repository (alte Revisionen) -> Reset commit-id -> Working Directory (die gewählte Revision)

Nja, wenn es ordentlich versioniert ist, dann kann ja nichts kaputt gehn, egal was du machst ... kannst ja immer wieder zu einem alten Stand zurück.


Es gibt ein paar nette Kurzübersichten über die wichtigsten Funktionen.
https://www.jrebel.com/blog/git-cheat-sheet (das Bild lässt sich auch gut auf A4 ausdrucken und neben den Monitor hängen)
https://dev.to/maxpou/git-cheat-sheet-advanced-3a17
https://github.github.com/training-k...heat-sheet.pdf
https://medium.com/@isamarietr/git-c...t-5c27a42f2c1a
git cheat sheet ...

Es gibt auch GUIs ala Tortoise-Git, da kannst im Log auf auf was gegen und einfach im Kontextmenü rumstöbern, bis sich was Passendes findet, wie z.B.

Delphi-Quellcode:

reset "master" to this

.
Auch wenn viele Linux-Gurus dir sagen werden GUI böse ... Console gut. :stupid:

[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:

Zitat von Sherlock (Beitrag 1457218)

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

:shock: 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:

Zitat von freimatz (Beitrag 1457291)

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:

Zitat von freimatz (Beitrag 1457291)

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:

Zitat von Sherlock (Beitrag 1457362)

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:

Zitat von Stevie (Beitrag 1457351)

Zitat:

Zitat von freimatz (Beitrag 1457291)

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.

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1457410)

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).

Wenn sie nicht mal mehr im reflog sind, dann sind 30 Tage vergangen, denn das ist die Standardeinstellung für wie lange unerreichbare Einträge dort vorgehalten werden (gc.reflogExpireUnreachable). Ansonsten muss man schon nen git reflog expire für aufrufen.

Zitat:

Zitat von freimatz (Beitrag 1457410)

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

Dito und ich war seinerzeit sogar für hg :wall: