1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Umstieg auf Git…

Die Frage die nach dem Artikel bleibt...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Die Frage die nach dem Artikel bleibt...

    Autor: flasherle 16.03.21 - 13:07

    ... ist, warum sollte man dies tun?

  2. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Bananularphone 16.03.21 - 13:28

    Weil Subversion, Clearcase, Perforce usw. scheiße sind?

  3. Re: Die Frage die nach dem Artikel bleibt...

    Autor: nomnomnom 16.03.21 - 13:35

    Danke für deine Meinung. Die Argumente haben mich überzeugt.

  4. Re: Die Frage die nach dem Artikel bleibt...

    Autor: KniKnaKnorke 16.03.21 - 13:50

    flasherle schrieb:
    --------------------------------------------------------------------------------
    > ... ist, warum sollte man dies tun?


    Die Vorteile bzw. Nachteile die GIT mit sich bringt, sollten wohl bekannt sein. Eine kurze Recherche sollte da genügen. Wir sind vor fünf Jahren auch auf Git(self hosted) gewechselt und dieses Jahr auf GitLab. Ein zurück auf SVN ist unvorstellbar. Denke es geht jedem so, der erst einmal die Flexibilität der Branches und den dezentral Ansatz von GIT kennengelernt hat.



    1 mal bearbeitet, zuletzt am 16.03.21 13:50 durch KniKnaKnorke.

  5. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Stefan Eßer 16.03.21 - 13:51

    flasherle schrieb:
    --------------------------------------------------------------------------------
    > ... ist, warum sollte man dies tun?

    Man sollte das wohl nicht tun, aber große Projekte mit vielen Beteiligten haben kaum eine andere Wahl.

    Bei FreeBSD war ausschlaggebend, dass ein sehr großes SVN-Repository (mit Sourcen, die ursprünglich mit RCS, dann mit CVS verwaltet worden waren) von hunderten von Entwicklern bearbeitet wurde.

    Immer mehr kamen mit GIT bzw. Github-Erfahrungen, wollten Pull-Requests einreichen können, waren nicht bereit ein anderes Tool zu erlernen als GIT.

    Die meisten Entwickler waren an den DCVS-Features nicht interessiert, es muss ohnehin weiterhin ein zentrales Repository mit fester Historie geben. Großen Wert hat man auf die Möglichkeit aufsteigender Commit-Nummern gelegt, z.B. um bei Schwachstellen angeben zu können, in welcher Revision sie behoben sind.

    Die Commit-Nummern werden durch Zählen der Commits im jeweiligen Branch des zentralen Repositories gebildet (also für jeden Release-Branch unabhängig, nicht eindeutig über alle Branches wie im SVN). Und wegen der Notwendigkeit alle GIT-Commits ins SVN exportieren zu können (wegen Tools von Downstream-Usern, die weiterhin SVN nutzen können sollen), gibt es starke Einschränkungen welche GIT-Operationen zulässig sind. Das wird man erst in einigen Jahren (nach Auslaufen des Supports für Releases die ursprünglich mit SVN verwaltet wurden) ändern können.

    Einige Entwickler nutzen die "billigen" Branches von GIT extensiv, aber für viele ändert sich nichts, außer dass man dem unglaublich schlechten User Interface von GIT (also der Struktur von Unterkommandos und Optionen von GIT, da müssen schon sehr viele Leute zusammen kommen, die zu Beginn nicht wissen, wo sie am Ende hin wollen ...) und der komplexen Abhängigkeiten beim Bauen bzw. Installieren von GIT.

    Das hierarchische Entwicklungsmodell von Linux (mit vielen Entwicklern auf "unterer Ebene", die weitgehend unabhängig voneinander arbeiten und deren Software dann von sehr wenigen "privilegierten" Personen ins zentrale "offizielle" Repository aufgenommen wird) lässt sich mit GIT besser abbilden als das "flache" Modell von FreeBSD, wo hunderte Entwickler gleichwertigen Schreibzugriff auf das Repository haben und nur unmittelbar vor einem Release ein Branch geschaffen wird, der Commits nur mit Freigabe durch den Release-Engineer zulässt.

    Aber wenn man Pull-Requests von Leuten außerhalb des Projektes annehmen können will, dann geht das über GIT und Github sehr viel einfacher. Dadurch wird dann zwar auch eine Hierarchie begünstigt, aber wer über längere Zeit interessante Beiträge liefert kann dann auch einen Account für direkte Commits ins zentrale Repository bekommen.

    Das FreeBSD-Repsository wird zwar auf Github als Read-Only-Mirror verfügbar gemacht, aber auf eigener Hardware gepflegt.

    GIT wurde von FreeBSD nicht wegen seiner Features ausgewählt (Mercurial hatte z.B. auch viele Verfechter), sondern ausschließlich wegen der breiten Nutzung von Github durch viele potentielle neue Entwickler, und auch wegen der dadurch einfach möglichen Automatisierung von Tests etc.

  6. Re: Die Frage die nach dem Artikel bleibt...

    Autor: katze_sonne 16.03.21 - 16:39

    Bananularphone schrieb:
    --------------------------------------------------------------------------------
    > Weil Subversion, Clearcase, Perforce usw. scheiße sind?

    Musste lachen. Ist halt wahr. Als nächstes zweifelt noch jemand an, dass der Himmel blau ist :D

  7. Re: Die Frage die nach dem Artikel bleibt...

    Autor: schnedan 16.03.21 - 16:43

    wir sollen auch auf git umstellen weil unser ALM System angeblich zukünftig nur noch git unterstützt... (auf der Herstellerseite finde ich dazu aber nix)

    aber ich mag git nicht... und nachdem ich mich mit den Interna und Konzepten jetzt näher beschäftigt habe mag ich es noch weniger. Teilweise funktioniert es nicht mal als DVCS - möchte man einem Kollegen was rüberpushen, ist der offizielle git weg: lege auf dem Server ein bare-Repro als Proxy an... Damit sind wir dann wieder auf dem technischen Stand von CVS und SVN... git, das Überlegene System! Das ich nicht lache.

    hg ist technisch und von der Design-Philosophie einfach das bessere System. Und ein echtes DCVS

    Leider setzt sich dank der Verbreitung mit git mal wieder das Nicht-Bessere-System durch...
    Mal googlen: Man muss Facebook nicht mögen... aber die behaupten ein Repro zu haben das weit größer ist als der Linuxkernel, und die haben hg ausgewählt (und stark verbessert). Früher hieß es immer git sei performanter als hg. Das stimmt wohl inzw. auch nicht mehr



    2 mal bearbeitet, zuletzt am 16.03.21 16:49 durch schnedan.

  8. Re: Die Frage die nach dem Artikel bleibt...

    Autor: KniKnaKnorke 16.03.21 - 17:45

    Am Ende zählt aber nicht ob ein einzelnes Tool besser ist als das Andere. Sondern wie gut das ganze Ökosystem aufeinander abgestimmt ist und welche Community sich darum bildet die es mit- und weiterentwickelt. Und da hat sich Git nun einmal durchgesetzt. Facebook baut sich halt einfach ein eigenes Ökosystem.

  9. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Allandor 16.03.21 - 18:16

    Bananularphone schrieb:
    --------------------------------------------------------------------------------
    > Weil Subversion, Clearcase, Perforce usw. scheiße sind?

    git aber auch.

    Habe selten ein schlechteres Source-Verwaltungstool gesehen. Hat allerdings erhebliche Vorteile bei der Automatisierung. Allerdings liegt das eher an der Community. Ist wie mit Javascript. Es hat die große Nachteile und große Vorteile ineinander Vereint.

    Das man sich mit git schon ein wenig auskennen sollte, sollte jedem spätestens dann klar sein, wenn man erfährt wie einfach man ein Repository für immer ins Jenseits schicken kann. Zum glück gibt es Backups.

  10. Re: Die Frage die nach dem Artikel bleibt...

    Autor: SirAstral 16.03.21 - 18:23

    Was ist an git schlecht?

  11. Re: Die Frage die nach dem Artikel bleibt...

    Autor: schnedan 16.03.21 - 18:35

    Ökosystem, Community?

    Ich habe jetzt für die tägliche Arbeit statt einem sauber strukturiertem Tool mit super Gui ein beschissenes CLI Tool. Das ist dann spätestens ab 2022 mein neues Ökosystem. Und meine Community bin ich selbst. Diese Community muss sich jetzt als erstes mal überlegen wie ich zukünftig mit git ohne Patchqueue zurecht komme... weil staging area und stash sind bei weitem kein funktioneller Ersatz für shelf und patch-queue. Auch das es sowas wie hg's phasen nicht gibt macht das Leben nicht einfacher.

  12. Re: Die Frage die nach dem Artikel bleibt...

    Autor: schnedan 16.03.21 - 18:36

    "Zum glück gibt es Backups."

    geiler Scherz!

  13. Re: Die Frage die nach dem Artikel bleibt...

    Autor: schnedan 16.03.21 - 18:44

    * Branching Konzept (keine Double Heads, branches existieren nicht dauerhaft (siehe hg named branches))
    * erlaubt das nachträgliche Manipulieren ders Repositories - selbst auf Servern (incl. das sich die Hashes ändern)
    * Merging Algorithmus ist schlechter als z.B. bei HG
    * Lass dir mal vom Kollegen n Verzeichnis mit nem Repro frei geben und pushe ihm mal was rüber zum reviewen... da kommt dann eine nette Fehlermeldung das man da ein bare repro als Proxy anlegen soll, weil man sich damit das tolle Branch Konzept von Git sonst zerschießen kann (Datenverlust in dem Repro in das man hineinpusht... drum gibt es auch in der Git welt diese idiotischen Pull-Requests - damit kaschiert man nur Designfehler des Tools!)
    * tags etc... werden nicht selbst versioniert verwaltet wie z.B. in hg
    *...

  14. Re: Die Frage die nach dem Artikel bleibt...

    Autor: mnementh 16.03.21 - 19:10

    Bananularphone schrieb:
    --------------------------------------------------------------------------------
    > Weil Subversion, Clearcase, Perforce usw. scheiße sind?
    Und dann wechselt man zu git, statt zu fossil oder hg?

  15. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Trockenobst 16.03.21 - 19:17

    schnedan schrieb:
    --------------------------------------------------------------------------------
    Grundsätzlich sollte man Prozessprobleme nicht mit einer Software lösen.

    > * Branching Konzept (keine Double Heads, branches existieren nicht
    > dauerhaft (siehe hg named branches))

    Double/Triple Heads sind ein Hack, weil man meist schlimme Softwarearchitekturen hat.
    Version 1.1, 1.2, 1.3, 1.4 haben wir parallel entwickelt, wenn man ein sauberes Modell hat, braucht man das nicht.

    > * erlaubt das nachträgliche Manipulieren ders Repositories - selbst auf
    > Servern (incl. das sich die Hashes ändern)

    git hält sich an die Systemrechte. Wenn du keine schreibrechte hast, geht das nicht.
    Kein Tool "löst" Prozessfehler von Menschen.

    > * Lass dir mal vom Kollegen n Verzeichnis mit nem Repro frei geben und
    > pushe ihm mal was rüber zum reviewen... da kommt dann eine nette
    > Fehlermeldung das man da ein bare repro als Proxy anlegen soll

    Das ist aber auch ein Prozessproblem. Das wilde rumspielen mit Branches der Kollegen sollte nicht die Regel sein. Wir haben personal Spaces, die man selbst managen kann, da gibt man den Kollegen Zugang zum richtigen Git und fertig. Ich geb dem Kollegen auch keine Sharefrei mit einer Datenbank drauf, der soll die schon richtig über Datenbankschnittstellen ansprechen.

    > * tags etc... werden nicht selbst versioniert verwaltet wie z.B. in hg
    Die annotated Tags werden von Git selbst als Objekt verwaltet. Oder ist was anderes gemeint.

  16. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 16.03.21 - 19:56

    flasherle schrieb:
    --------------------------------------------------------------------------------
    > ... ist, warum sollte man dies tun?

    svn ist wirklich stupide. Es trackt Dateien über Datei-Pfade und nicht über Hashes. Wenn du bspw. n identische Configs hast, dann kommen die physikalisch n mal vor.
    Auch, wenn du auf Dateisystemebene Dateien verschiebst oder umbenennst, kriegt das svn nicht mit.

    Weiter, kannst du nicht mehr Committen, wenn der Server ausfällt. - Wir hatten mal einen Cyberangriff und wir mussten 2 Wochen ohne Server auskommt. Lokal konnte man hingegen immer noch Branches erstellen und committen. Und jemand, der nicht den neuesten Stand hatte, weil er im Urlaub war, dem konnte man das Git-Repo einfach per USB zur Verfügung stellen.
    Wer jetzt kritisiert, weshalb, es so lange gebraucht hat, bis wieder alles online war: Es geht bei einem Cyber-Angriff nicht einfach nur darum, das Backup aufzuspielen, sondern auch, um Analyse und weitere Angriffe zu verhindern.

  17. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Panzergerd 16.03.21 - 21:51

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > svn ist wirklich stupide. Es trackt Dateien über Datei-Pfade und nicht über
    > Hashes.
    git ist aber auch stupide. Ich habe neulich von einem Branch einen neuen abgebrancht, und auf dem neuen Branch ein Verzeichnis mit diversen Unterverzeichnissen verschoben (mit git mv). Auf dem alten Branch wurde dann ein neues Unterverzeichnis angelegt unterhalb des verschobenen Parents. Als der alte Branch erneut in den neuen Branch gemerged wurde, hätte ich von git erwartet dass das neue Unterverzeichnis im verschobenen Parent auftaucht. Pustekuchen, ich musste das nach dem Mergen von Hand verschieben.

  18. Re: Die Frage die nach dem Artikel bleibt...

    Autor: Steffo 16.03.21 - 22:40

    Gegenfrage: Welches Versionskontrollsystem würde sich da anders verhalten?

    Ich bin mir auch nicht sicher, ob das ein dummes Verhalten ist. Ich könnte mir vorstellen, dass man mehr kaputt machen kann, wenn man eine Ordner-Hierarchie-Logik einbaut.

  19. Re: Die Frage die nach dem Artikel bleibt...

    Autor: dummzeuch 17.03.21 - 10:56

    flasherle schrieb:
    --------------------------------------------------------------------------------
    > ... ist, warum sollte man dies tun?

    Ganz genau diese Frage stelle ich mir schon seit einigen Jahren. Ich habe mehrfach angesetzt git für kleinere private Projekte zu nutzen und bin jedes Mal wieder bei Subversion gelandet.

    Die verteilte Struktur von git brauche ich weder privat noch für die Arbeit, bei letzterem ist ein zentrales Repository sowieso Voraussetzung. Die deutlich komplexere Handhabung ist definitiv ein Nachteil. Die Tools, zumindest die, die ich mir angesehen habe, sind deutlich schlechter als TortoiseSVN, welches wir zur Zeit einsetzen. Lediglich das Merging soll besser sein.

    Noch viel schlimmer: Ich persönlich könnte vielleicht auf git umsteigen, aber mir graut bei dem Gedanken, was so mancher Kollege, der schon mit SubVersion seine Schwierigkeiten hat, mit einem komplexen Tool wie git für einen Unsinn anstellen könnte. Ich denke da an Software-Releases, deren Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar jetzt schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das haben wir schon durch.)

  20. Re: Die Frage die nach dem Artikel bleibt...

    Autor: mnementh 17.03.21 - 11:39

    dummzeuch schrieb:
    --------------------------------------------------------------------------------
    > Die verteilte Struktur von git brauche ich weder privat noch für die
    > Arbeit, bei letzterem ist ein zentrales Repository sowieso Voraussetzung.
    Ja, git ist für Linux entwickelt worden und deckt die Arbeitsweise im Linux-Projekt gut ab. Aber Linux hat die wahrscheinlich ungewöhnlichste Projektorganisation, auch andere große Open-Source-Projekte sind anders organisiert.

    > Die deutlich komplexere Handhabung ist definitiv ein Nachteil.
    Das hat mich schon immer genervt mit git. Für viele einfache Sachen muss ich dann doch nachschauen, weil der Zusammenhang von Befehlen oder Optionen für Befehle nicht immer klar ist. In SVN kommt man meist ziemlich direkt von dem was man will zum richtigen Befehl.

    Das git-Kommandozeilen interface bräuchte ein Redesign mit einer durchgehenden Philosophie.

    > Die Tools,
    > zumindest die, die ich mir angesehen habe, sind deutlich schlechter als
    > TortoiseSVN,
    Die Tool-Situation bessert sich ja, aber ja, SVN hat da immer noch die Nase vorn.

    > welches wir zur Zeit einsetzen. Lediglich das Merging soll
    > besser sein.
    >
    Ehrlich gesagt hatte ich sowohl mit SVN als auch git meine Merging-Probleme und Situationen die reibungslos gingen. Ich bin mir nicht wirklich im Klaren wo der klare Merging-Vorteil von git liegt.

    Und ganz generell gibt es einfach Dinge bei SVN, die andere Systeme nicht gut gelöst haben. Das mögen Kleinigkeiten sein, wie dass ich nach der Nutzung von svn:ignore-Properties eine .gitignore-Datei archaisch finde (ich habe noch mit CVS gearbeitet, und in mancher beziehung gibt mir git Flashbacks an diese dunkle Zeit). Oder aber es sind größere Dinge, wie dass ich mit svndump und svndumpfilter relativ einfach Repositories mergen kann oder einen Teilzweig in ein eigenes Repository extrahieren kann. Mit kompletter Historie natürlich. Bei git überlege ich mir besser vorher sehr genau, was zusammen in ein Repository gehört und was in getrennte kommt, weil das später nur schwer änderbar ist.

    > Noch viel schlimmer: Ich persönlich könnte vielleicht auf git umsteigen,
    > aber mir graut bei dem Gedanken, was so mancher Kollege, der schon mit
    > SubVersion seine Schwierigkeiten hat, mit einem komplexen Tool wie git für
    > einen Unsinn anstellen könnte. Ich denke da an Software-Releases, deren
    > Sourcecode nur in seinem lokalen Repository liegt, weil er verschusselt
    > hat, es in das zentrale Repository zu übertragen. Es kommt ja sogar jetzt
    > schon vor, dass Sourcecode wochenlang nicht im Repository landet. (Und
    > komme mir keiner mit "Dann braucht Ihr halt eine Schulung dafür.", das
    > haben wir schon durch.)
    Haha, ich kenne Experten die sind schon so weit dass ins zentrale Repository zu übertragen, haben aber ihre eigenen Branches angelegt (auch benannt beispielsweise Stefans branch oder so), arbeiten dort wochenlang für sich selbst und erwarten dann von mir dass ich das in den Hauptzweig merge. So nicht. Ich erwarte dass die Leute wissen wozu sie einen Branch aufmachen, wann er endet und ob es zurück in den Hauptzweig gemergt werden soll oder separat bleibt (gepflegte Legacy-Version beispielsweise).

    BTW, hast Du mal fossil ausprobiert? Für meine privaten Projekte gefällt mir das inzwischen am Besten.
    https://fossil-scm.org/
    Der coole Trick ist, dass hier Wiki, Tickets usw. zum Repository gehören. Das Ticketsystem braucht noch Arbeit IMHO, da bevorzuge ich noch etwas externes. Aber Wiki usw. ist schon recht cool. Und da fleißig dran gearbeitet wird bin ich zuversichtlich, dass das Ticketsystem noch besser wird.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Projektmanagement-Officer (w/m/d)
    Salzgitter Mannesmann Handel GmbH, Düsseldorf
  2. Referentin / Referent für den Bereich Organisations- und Informationsmanagement (m/w/d)
    Kommunale Gemeinschaftsstelle für Verwaltungsmanagement (KGSt), Köln
  3. Product Owner (m/w/d)
    QUNDIS GmbH, Erfurt
  4. Senior Security Consultant (m/w/d)
    NTT Germany AG & Co. KG, Bad Homburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Days Gone für 22,49€)
  2. (u. a. MacBook Pro 14 Zoll M1 Pro Chip mit 8‑Core-CPU und 14‑Core GPU 16GB 512GB SSD für 2...
  3. (u. a. MacBook Pro 16,2 Zoll M1 Pro Chip mit 10-Core-CPU und 16-Core-GPU 16GB 1TB SSD für 2.979€)
  4. 33,99€/Monat für 24 Monate + 1€ einmalige Kosten


Haben wir etwas übersehen?

E-Mail an news@golem.de


Minidisc gegen DCC: Der vergessene Formatkrieg der 90er-Jahre
Minidisc gegen DCC
Der vergessene Formatkrieg der 90er-Jahre

Vor 30 Jahren hat Sony die Minidisc als Nachfolger der Kompaktkassette angekündigt - und Philips die Digital Compact Cassette. Dass sich an diese nur noch Geeks erinnern, hat Gründe.
Von Tobias Költzsch


    Radeon RX 6600 im Test: Die bisher günstigste Raytracing-Grafikkarte
    Radeon RX 6600 im Test
    Die bisher "günstigste" Raytracing-Grafikkarte

    Mit der sparsamen Radeon RX 6600 lässt sich in 1080p gut spielen, für Raytracing-Grafik müssen aber bestimmte Punkte erfüllt sein.
    Ein Test von Marc Sauter

    1. Radeon RX 5000 AMD-Treiber verbessert Leistung älterer Grafikkarten
    2. RDNA2-Grafikkarte Radeon RX 6600 XT ab 430 Euro lieferbar
    3. Radeon RX 6600 XT im Test Wenn die Unendlichkeit bei 1080p endet

    Probefahrt mit BMW i4 M50: Für mehr Freude am Fahren
    Probefahrt mit BMW i4 M50
    Für mehr Freude am Fahren

    Der neue BMW i4 M50 bringt seine 400 kW Motorleistung sehr souverän auf die Straße. Und das auf einer Verbrennerplattform.
    Ein Bericht von Friedhelm Greis

    1. Daymak Spiritus Elektroauto macht Krypto-Mining auf drei Rädern
    2. Foxconn Eigene Elektroautos unter dem Namen Foxtron vorgestellt
    3. E-Kleinstwagen Microlino bekommt ein Exoskelett als Offroader