Bonobo GIT Server
« | 17 Nov 2018 | »Eine der Nachwirkungen meines Server-Crashes ist, dass ich der Versionsverwaltung GIT nun doch etwas mehr abgewinnen kann.
Bisher war ich (einer der letzten) Verfechter von SVN.
Nun ist mir zwar durch den Crash keine Zeile Quellcode verloren gegangen (glaube ich), doch der Wiederaufbau von SVN aus veralteten Backups ist auch nicht ganz das Wahre.
Für mich privat ist es tatsächlich vollkommen egal, welches System ich zu Hause einsetze. Relevanter Code sind ohnehin in der Cloud.
Mein bisher größtes Gegenargument zu GIT war das Zersplittern der Arbeitsbereiche und das späte Zusammenführen der Daten in Teams. Wenn es keinen gemäßigten Zwang gibt, seine Ergebnisse auf einen Server zu übermitteln, dann tun die Entwickler das auch nicht, bzw. viel zu selten. Und das führt dann zwangsläufig zu einem angestellten Beamten, der dann schwer von einander abweichende Codes im gleichen Modul “irgend wie” zusammenführen soll.
Ich gebe aber zu, dass das vielleicht eher einer nicht optimalen Arbeitsweise zuzuschreiben ist, die ich in GIT Teams häufiger erlebt habe, als bei SVN Teams. (Soll heißen: Es ist kein grundsätzliches GIT-Problem.)
Im Netz führt das permanente forken zu tausenden Nebenprojekten, die ebenfalls vieles doppelt und dreifach machen. Linux und seine Distributionslandschaft zählt für mich zu einem Beispiel für eine verteilte Sisyphusaufgabe.
Und daher finde ich ein zentrales Reglement, wie es von BSD Projekten betrieben wird, grundsätzlich sinnvoller.
Ich habe nun kurzerhand den Bonobo GIT Server auf meinem Windows-Server installiert.
Die Installation war einfach (Copy & Paste), nur die Integration ins
Active Directory erforderte eine manuelle Anpassung der web.config Datei.
Und selbst das war ohne Probleme in wenigen Minuten erledigt.
Natürlich kann ich noch nicht über das System urteilen, aber es macht zumindest auf den ersten Blick mal einen vernünftigen Eindruck.
GIT speichert die Historie der Änderungen auch auf den Clients und so kann man auch offline nach Änderungen suchen, was bei SVN nur mit verbundenem Server möglich ist.
Sollte es - Gott behüte - wieder mal einen Ausfall geben, lässt sich das Repository vielleicht mit Hilfe der Clients wiederaufbauen … so zumindest die Theorie.
Andererseits ist das - wie gesagt - bei mir keine Notwendigkeit. Seit 15 Jahren habe ich noch nie bewusst nach älteren Ständen in meiner Codebase gesucht. Für gewöhnlich ist immer die neueste die beste. (Einzige Ausnahme sind bei ausgelieferten Produkten ‘neu’ eingearbeitet Bugs, die eine ältere Version noch nicht hatte.)