Git anschaulich erklärt

@GambaJo das Wichtigste, was man bei Git verstehen muss, sind die grundlegenden Architekturfehlentscheidungen und warum es daher kein DVCS ist und eigentlich ein ziemlich mieses Tool - verstehen aber nur Leute, die mercurial kennen, dass das alles richtig macht... [und auch als DVCS funktioniert]

Seit wir in der Firma von hg auf git gewechselt sind, hat sich mein zeitlicher Aufwand beim Hantieren mit den Repositorys grob ver50facht.

@schnedan Hmm, laut Wikipedia (und meinen langjährigen Erfahrungen ist git ein DVCS. Das war die Hauptmotivation für die Entwicklung von git.

Ich habe noch nie mit Mercurial gearbeitet, daher kurz recherchiert. So wie ich das verstanden habe, und was auch KIs sagen, Mercurial ist etwas einfacher, aber weniger Feuters und weniger Flexibilität. Aber im Grunde ähneln sie sich doch stark.

Mir sind auch keine grundlegenden Architekturfehlentscheidungen bekannt. Würde mich auch wundern, ist es doch mittlerweile ein De-facto-Standard in der Softwareentwicklung. Hätte sich sonst auch nicht durchgesetzt.

Welche Architekturfehlentscheidungen meinst Du konkret?

@GambaJo Git hat ein defektes Branching - branches bei git sind nur Pointer die man bel. manipulieren kann. Commits wissen nicht auf welchem Branch sie erzeugt wurden (hg kann das auch, nennt sich da bookmarks).
Damit gibt es bei git detached heads - das gibts bei hg nicht, je nach dem wie man merged und branches manipuliert kannst bei git nach einiger Zeit nicht mehr sagen wo und warum ein commit erzeugt wurde - git kann dir nur sagen welche aktuellen branchpointer durch den graph eltern eines alten commits sind. Daher gibts so krücken das bestimmte tools immer den branchnamen mit in die Commitmessage schreiben oder sowas wie diese gitflows.

Außerdem kannst du daten zerstören wenn du nicht über ein zentrales repro synchst - daher ist das inzw. per default abgeschalten.

@GambaJo Das war das D in DVCS.

hg hingegen hat echte branches, jeder commit weis auf welchem branch er erzeugt wurde. du kannst also Historie zu 100% wieder herstellen. Auch ist das manipulieren des Repros per default abgeschalten. Normale User sollten das auch nicht tun dürfen.

für dich lokal bietet hg auch Wegwerfbranches wie git (die Bookmarks...).

Da hg eine saubere Architektur hat, brauchst du keine zentralen Repros - die sind optional.

Ach ja und shelfs und die Patchqueue von hg sind viel leistungsfähiger als gits staging und stashes...

@schnedan Das unterstreicht das, was ich gesagt habe. git ist nicht so einfach, daber flexibler. Die Konzepte sind etwas unterschiedlich, man muss sie richtig bedienen/wissen, was man tut. Mir sind mit git noch nie Daten abhanden gekommen.

Bei git braucht man keine zentralen Repros. Man kann welche einrichten, muss es aber nicht. Und selbst wenn man welche hat, hat jeder User einen kopletten Klon auf seinem System und ist unabhängig von einem anderen Repo. Da sind wir wieder bei der Fkexibilität.

Ich weiß nicht, wie belastbar das ist, aber Mercurial-Nutzer sollen „Bookmarks“ statt Branches bevorzugen, die ja ähnlich den Branches in git sein sollen.

@GambaJo ja ne. Git ist nicht flexibler. Alles was Git da kann, kann hg auch.

Wenn du von Rechner A auf Rechner B pushst (wie gesagt inzw. deaktiviert) kannst da git dazu zwingen Daten auf B zu ändern die nicht commited sind. bei HG gibts einfach einen 2ten Head im Branch - sieht unschön aus ist aber sicher.

"Bei git braucht man keine zentralen Repros." theoretisch nicht, aber selbst die Git Doku redet von nix anderem mehr, weil nur so funktioniert git auch für DAUs die sich nicht mit den Interna beschäftigen.

Auch speichert Git bestimmte Dinge nur in deinem lokalen Reflog. D.h. man kann bestimmte Schritte der Vergangenheit nur an dem Rechner nachvollziehen an dem sie gemacht wurden. bei hg haben alle Repros die volle Info.

@GambaJo in der Mitte der Page mal nach "Git is not really about branches" suchen

https://stackoverflow.com/questions/61936264/understanding-the-git-graph

@schnedan In dem von mir geposteten Video wird genau das gesagt. Es ist einfach nur ein etwas anderer Ansatz, der nicht zwingend falsch ist. Es erfordert eventuell eine etwas andere Nutzung.
Wenn das nicht funktionieren würde, würde vermutlich 95% der Softwareentwicklung aktuell nicht funktionieren.

@GambaJo wie gesagt, meiner Meinung nach ist das Wichtigste das man alte Stände zu 100% wieder herstellen kann. Um auch nachvollziehen zu können wer was wann und warum getan hat.

Mit git kann man die Dateien zurücksetzen, viele Metadaten sind aber verloren. Branches und Tags werden nicht auf die alten Stände zurückgesetzt wenn man einen alten Commit auscheckt. Bei komplexen Projekten, ohne Krücken wie strenge Mergeregeln im Projekt, kann git die Historie nicht komplett wieder herstellen

Damit versagt git in der Kernaufgabe jedes VCS.

Kommt noch dazu das 99% meiner Kollegen sich nie die Mühe machen die Interna der Tools zu lernen, merken die nicht einmal das sie ständig Metadaten vernichten... git macht das aber halt sehr einfach, weil es der default ist.