Kinder entdecken die Welt. Heute: Git

[Andreas Karg]

An anderer Stelle wurde ich gebeten, ein bisschen was über Git zu schreiben.

Eins vorweg: Alles, was man über Git wissen sollte, möchte, muss oder kann, steht bereits im Netz. Es gibt ein offizielles Buch namens Pro Git, das nichts kostet. Google spuckt zu so ziemlich jedem Git-Problem einen Artikel auf Stackoverflow, einer Frage/Antwort-Seite, wo viele kluge Menschen, anderen Menschen ihre technischen IT-Fragen beantworten.

Darüber hinaus erhebe ich natürlich keinen Anspruch auf Unfehlbarkeit und Vollständigkeit. Wer Fehler findet, darf, nein soll sie melden, damit ich sie korrigieren kann. Und wenn weitere Fragen auftauchen, steh ich natürlich auch zur Verfügung.

Aber fangen wir an...

Git ist ein so genanntes Versionskontrollsystem. Andere Vertreter dieses Genres heißen CVS, SVN, Mercurial ("Hg") oder Bazaar, um mal nur die vermutlich bekanntesten zu nennen. Worum geht es dabei? Nun, vermutlich wird jeder, der an seinem Rechner schon irgendeine größere Form (>30min) von Arbeit erstellt hat, mal vor dem Problem gestanden haben: Ich will jetzt mal was ausprobieren. In einer Konstruktion ein Bauteil größer machen, Formatierung vom Dokument umschmeißen, 300 Programmzeilen löschen oder eine Lokomotive auf Nuklearantrieb umrüsten.
Wurschtegal, was es ist, der klassische Ansatz geht so:

• Sicherungskopie von Hand machen
• Experiment durchführen
• Ggf. neue Version löschen und Sicherungskopie zurückkopieren

Dann löscht man natürlich die Sicherung nicht sofort, weil vielleicht könnt man sie ja nochmal brauchen. 20 Minuten später: Och, so könnte das klappen.
Die Folge: "Mein Werk - Kopie(2).dings"

Drei Tage später krebbst man mit einem Ordner voller kryptisch benannter Sicherungskopien durch die Gegend und hat keine Ahnung mehr, was jetzt eigentlich wo drin ist. Und so richtig gesichert sind ja diese Sicherungskopien auch nicht: Kackt die Festplatte ab, sind sie mitsamt dem Original über'n Jordan. Nun kann man das Zeug natürlich auch noch anderswo hinkopieren - wahlweise von Hand oder von einem automatisierten Backuptool.
Was bleibt ist aber, dass es meiner Meinung nach ein ganz schreckliches Gefrickel ist.

Und genau an dieser Stelle kommen Versionskontrollsysteme (VCS) ins Spiel. Ich bleibe hier mal ein bisschen allgemein, weil die Grundlagen ja kein Alleinstellungsmerkmal von Git sind.

Mit einem VCS erschlägt man die ganze obige Problematik auf einmal. Daten werden in allen mir bekannten VCS in Projekten, genannt "Repositories", organisiert. Wenn ich mit meinen Daten arbeiten möchte, hole ich mir aus dem Repository eine Arbeitskopie ("working copy"). Am Anfang ist das ein ziemlich leerer Ordner.

Nehmen wir nun mal an, ich hab mir was ganz Tolles ausgedacht und fange an, an "Mein Werk.dings" zu arbeiten. Ein Repository existiert schon und ich habe mir den aktuellen Zustand des Repositories in eine Arbeitskopie gezogen, die momentan aus einem leeren Ordner besteht.
Ich bastele ein wenig herum und beschließe, dass diese Grundlagen ausreichen, um sie mal zu sichern. Also teile ich meinem VCS mit, dass es bitteschön die "Mein Werk.dings" in das Repository aufnehmen möge, und zwar in genau diesem Zustand. Guad, sagt das VCS, homma erledigt, is g'speichert. Ein solcher gespeicherter Zustand heißt "Commit" und dieses Exemplar nenne ich jetzt einfach mal "(A)".

Man kann sich üblicherweise die Historie ("Log") seines Repositories angucken. Den Commit, auf dem die Arbeitskopie gerade basiert, markiere ich mit einem *. Das sieht also gerade so aus:

Code: Alles auswählen

(A*)

Zwei Stunden später: Es funktioniert! Es gibt ein erstes lauffähiges Dings. Gleich sichern. Also wieder das VCS bemühen: Bitteschön den aktuellen Zustand von "Mein Werk.dings" und die beiden neuen Dateien "Hilfsdings A.dings" und "Hilfsdings B.dings" mitspeichern. Also wieder einen neuen Commit erstellen. Der neue Commit heißt (B) und baut auf (A) auf. Commits, die aufeinander aufbauen, verbinden wir mit einer Linie. Neuere Commits landen in der Grafik rechts. Also haben wir folgendes Log:

Code: Alles auswählen

(A)--(B*)

Neuer Tag, neues Glück: Ich hab' schon wieder eine neue Idee! Und das Beste: Ich kann dafür die Grundlagen aus dem ersten Commit benutzen, den Rest... na, schaumermal.
Also, VCS: Gib mir (A) nochmal! Zack! Die beiden Hilfsdingse sind verschwunden und ich habe wieder meinen Ordner genau so, wie er damals war:

Code: Alles auswählen

(A*)--(B)

Nun bastele ich weiter und erreiche irgendwann einen weiteren zu sichernden Zustand:

Code: Alles auswählen

(A)--(B)
   \-(C*)

Was ich hier gemacht habe, ist eine Verzweigung; ich habe stillschweigend einen neuen "Branch" angelegt. Was das Branching angeht, gehen die Konzepte der verschiedenen VCS mehr oder weniger krass auseinander. Git ist bisher das einzige, mit dem ich über längere Zeit ernsthaft gearbeitet habe, deswegen kenne ich mich auch nur da wirklich aus. Aber nach allem, was ich gehört habe, gelten Zweige im Vergleich zu anderen VCS bei Git als überaus einfach zu bewerkstelligen: Man verzweigt einfach munter drauflos. Wie genau, erklär' ich später.

Aber nun! Ich stelle fest, dass mein Werk aus (B) wunderbar zu dem aus (C) passt. Ich hätte schon sehr gerne beides zusammen. Zu diesem Zweck gibt es den "Merge", also die Zusammenführung. Ich kann dem VCS sagen, dass es doch bitte (B) und (C) zusammenführen und das Ergebnis (D) nennen soll:

Code: Alles auswählen

(A)--(B)-\
   \-(C)--(D*)

Für diesen Merge kommen mehr oder weniger intelligente Algorithmen zum Einsatz, die B und C soweit zusammenfieseln sollen, dass es keine Konflikte gibt. Nehmen wir an, ich habe in (A) mit einem Klotz angefangen. In (B) habe ich auf der einen Seite ein Loch reingemacht. Und in (C) gibt es kein Loch, aber dafür eine Rille am anderen Ende des Klotzes, die mit dem Loch aus (B) rein gar nichts zu tun hat. Der Merge-Algorithmus wird feststellen, dass ein Klotz mit Loch und Rille kein Problem ist, und mir einen solchen ausspucken.

Aber stellen wir uns vor, dass ich auf meinem Klotz eine Stange habe. In (A) hab ich sie einfach mal 10cm lang gemacht. Für (B) musste sie 20cm lang werden und in (C) sogar nur 5cm. Wenn ich jetzt (B) und (C) miteinander vereine: Wie lang wird die Stange? Sowas nennt man dann Konflikt. Kein Algorithmus dieser Welt wird sich für eine sinnvolle Stangenlänge entscheiden können. Er wird dann erst mal weitermachen und alles so gut zusammenführen wie er kann, und mir dann eine Fehlermeldung ausspucken, dass ich mir die Stange mal angucken soll. Erst, wenn ich das erledigt und dem VCS gesagt habe, dass die Stange jetzt die richtige Länge hat, wird Commit (D) wirklich erzeugt. Mit Loch und Rille und passender Stange.

Aber Achtung: Der Merge-Algo wird nur feststellen können, dass sich Loch und Rille nicht in die Quere kommen. Es kann natürlich genausogut sein, dass nur das Loch oder nur die Rille sinnvoll sind und beides zusammen sogar schädlich. Deswegen sollte man sich seine Merges nochmal gut angucken, ob das auch wirklich so passt, was der Automat da produziert hat.

Es hindert mich natürlich niemand daran, jetzt wieder bei (B) weiterzumachen und auf (B) aufbauend (E), (F) und (G) zu erzeugen und dabei (D) komplett außen vor zu lassen:

Code: Alles auswählen

(A)--(B)\-(E)-(F)-(G*)
   \-(C)--(D)

Damit haben wir eigentlich schon den Grund-Werkzeugbaukasten, den man für eine produktive Arbeit mit einem VCS braucht, erledigt:
Repository anlegen, Dateien hinzufügen, Neue Commits erzeugen, zu alten Commits zurückgehen, Zweige anlegen und bei Bedarf wieder zusammenführen.

Mein Plan für den nächsten Eintrag:

• Zentrale VCS vs. Verteilte VCS (ggf. mit zentraler Sicherung)
• Erste Schritte mit (Tortoise-)Git
• ..?

Wie gesagt: Fragen, Anmerkungen, Kritik, etc. sind gerne willkommen. Ich hoffe, es war einigermaßen lesenswert und lehrreich und wünsche nun erst mal eine angenehme Nachtruhe.

[Johannes]

Andreas, der Beitrag ist wirklich informativ und auch lesenswert. Für jemanden, der das Konzept von VCS noch nie gehört hat, ist es hoffentlich nicht zu abschreckend, wenn du gleich mit Branching und Merging beginnst.

Daher vielleicht für „Anfänger“ nochmals kondensiert: Ein VCS ist in seiner einfachsten Form erst mal ein System, das verschiedene Zwischenstände meiner Arbeit archiviert. Das gibt mir die Sicherheit, nach Herzenslust an der Datei herumzubasteln – alle alten Version sind immer noch da und werden es auch immer bleiben. Als hübscher Nebeneffekt kann ich zu jedem Zwischenstand hinzuschreiben, was ich im Vergleich zum vorherigen geändert habe, und so meine Arbeit dokumentieren.

Moderne VCS haben nun den Vorteil, auch nicht-lineare Arbeitsweisen abbilden zu können. Das muss nicht jedermanns Ding sein, das Wissen um diese Funktionen kann aber durchaus nützlich sein. Daher lohnt es sich, Andreas’ Beitrag einmal gut durchzulesen und sich das Konzept von Versionsständen, die aufeinander aufbauen, zu verinnerlichen.

Grüße
Johannes

[Roland Ziegler]

@AndiK: Ich dachte, der Git-Hype wäre inzwischen vorbei.

[Dennis Bork]

Danke Andreas für die sehr gut geschriebene Einführung. Ich bin inzwischen dank dem Git-Book http://git-scm.com/book" target="_blank schon etwas weiter und entwickle gerade fleißig (zwei freie Tage) an meinem ZusiMeter, basierend auf der Zielbremsen-Anwendung. Da ist git schon sehr praktisch!

Wenn Du auf git log zu sprechen kommst kannst Du ja kurz die praktischsten Formatierungen ansprechen und vielleicht auf das von der git bash aufzurufende gitk zu sprechen kommen!

[Andreas Karg]

Roland, ich hype hier überhaupt nichts. Ich habe diverse VCS durchprobiert; angefangen mit CVS über SVN, Mercurial, kurzzeitig Bazaar und eben Git. Und für mich persönlich ist Git das, was am ehesten meinen Bedürfnissen entspricht. Dementsprechend gut kenne ich mich mit Git aus und mit den anderen eben nicht. Ich habe versucht, meinen ersten Beitrag so allgemein wie möglich zu halten, damit niemand auf die Idee kommt, es könne sich um Alleinstellungsmerkmale handeln, die keine sind.
Es steht jedem frei, einen vergleichbaren Beitrag über das jeweils präferierte VCS zu verfassen; dann kann sich jeder Neuling das raussuchen, was ihm am ehesten taugt. Ich bin auch niemandem böse, wenn ich fast der einzige bleibe, der Git toll findet.

Nachtrag:
Danke an die anderen für die aufmunternden Kommentare und Anmerkungen. :-)

[Roland Ziegler]

Ich habe diverse VCS durchprobiert; angefangen mit CVS über SVN, Mercurial, kurzzeitig Bazaar und eben Git. Und für mich persönlich ist Git das, was am ehesten meinen Bedürfnissen entspricht. Dementsprechend gut kenne ich mich mit Git aus und mit den anderen eben nicht.

Dein erster und Dein zweiter Satz widersprechen sich ein wenig.

Aber wesentliches kommt rüber: Es ist aus Deiner Sicht und aus Deinen Bedürfnissen.

Gestatte mir eine emotionale Anmerkung vorweg: Wenn ein Produkt von seinem Schöpfer als allein selig machend gepriesen wird und derjenige für andere Produkte explizit Hass empfindet und dies auch noch öffentlich zum Ausdruck bringt, und seine Jünger dann diese Auffassung als Weltanschauung vor sich her tragen, dann bewirkt dergleichen bei mir das ganze Gegenteil von dem, was beabsichtigt war: Das Produkt kommt zunächst einmal für mich (und meinen Verantwortungsbereich) nämlich gerade nicht in die engere Auswahl.

Sicher tut man Git damit Unrecht und sicher muss man zugestehen, dass vor allen bei jungen Anhängern der Linux-Welt die Religion wichtiger als die Sache ist, aber es kann ganz praktische einschränkende Auswirkungen haben. Die Verklärung führt nämlich zu erhöhtem Grundrauschen im Netz, was bei der Recherche zu Antworten auf Sachfragen durchaus hinderlich ist.

Nüchtern betrachtet sollte man sich der Fragestellung Versionsmanagement und wenn ja welches von den eigenen Anforderungen her nähern. Die Auswahl des Produktes steht am Ende, nicht am Anfang. Und man sollte vor allen die Anforderungen nicht im Nachhinein auf die Vorauswahl des Produktes anpassen.

Warum will man also Versionsmanagement einsetzen wollen:

• Der erste, und für einen Großteil von Projekten auch einzige Grund, ist der eines soliden und strukturierten Backups.
• Ein zweiter ist die passive Teilhabemöglichkeit für andere Nutzer, also Versionsmanagement als Werkzeug zur Verbreitung. Die hiervon profitierenden Projekte sind aber schon weniger.
• Erst an dritter Stelle steht die aktive Teilhabe von mehr als einem Entwickler. Und ab hier wird es dann auch bald etwas anspruchsvoller.
• Branching und Merging hingegen interessiert nur noch einen relativ kleinen Teil der Anwender, gerade wegen der damit verbundenen Komplexität.

Versionsmanagementsysteme bieten einen mehrdimensionalen Blick auf die von ihnen verwaltete Welt:

• Da ist zunächst die Welt selbst, also der Umfang der Dateien, meist hierarchisch gegliedert.
• Die zweite Dimension ist die der Zeitachse, der Zustand und Inhalt der Dateien über die gesamte Entwicklungsgeschichte.
• Die dritte Dimension ist die des Verzweigens in verschiedene Entwicklungsstränge und ggf das Wiederzusammenführen (Branching und Merging).
• Sogenannte verteile Versionsmanagementsysteme bringen noch eine vierte Dimension ein, nämlich die der Mehrschichtigkeit des Repositories selbst.

Der Begriff Dimension weist hin auf Orthogonalität. Jede neue Dimension bringt zusätzliche Komplexität. Um den vierdimensionalen Raum noch beherrschbar zu machen, schränken Produkte den dreidimensionalen Raum u.U. ein.

Aus den angeführten Punkten heraus finde ich es erstaunlich, dass man immer wieder ausgerechnet eines der komplexesten Produkte als Lösung für eher bescheidene Projekte hingestellt bekommt. Eine typische Entschuldigung auf Nachfrage lautet dann, man würde mit der inhärenten Komplexität ja gar nicht konfrontiert, weil man sie nicht nutze.

Nun gut. Große Projekte sind ja mitnichten in Scharen zu Git übergelaufen. Selbst bei durchaus vergleichbarer Projekt- und Entwicklungsstruktur halten viele am "nur" dreidimensionalen System fest. Wer möchte schon seine Hauptbeschäftigung als Integrationsbeauftragter sehen.

[Jens Haupert]

Hallo,

irgendwie kommt mir die Diskussion bekannt vor.

Gruß an Roland.

[BorisM]

@Roland: Jetzt würde mich mal interessieren, was denn so die von Dir bevorzugte Versionsverwaltung ist. Ich nutze für mein Projekt SVN, und bin damit recht zufrieden, allerdings sind meine Anforderungen jetzt natürlich nicht so groß. Allerdings habe ich noch keine graphische Oberfläche dafür gefunden die mir gefällt, und mach daher alles mit Konsolenbefehlen.

[Johannes]

Ich finde Git nicht wesentlich komplexer als andere Versionskontrollsysteme (mit Front-Ends wie Tortoise* wird die Bedienung eh vereinheitlicht). Dafür bietet es aus meiner Sicht folgende Vorteile gegenüber anderen VCS (meine Erfahrung beruht auf CVS und SVN):

• Es ist offline: Man kann sämtliche Operationen außer dem Synchronisieren mit anderen Repositories ohne Internetverbindung durchführen. Für mich der größte Vorteil!
• Es ist schnell (folgt teilweise aus dem ersten Punkt).
• Es ist verteilt: Wenn bei SVN der zentrale Server mit dem Repository abschmiert oder nicht erreichbar ist, habe ich ein Problem. Bei Git dagegen ist jedes Repository, auch das auf meinem eigenen Computer, gleichberechtigt.
• Es ist modern: Etwa in SVN werden Dinge wie Branching nicht nativ unterstützt (stattdessen muss man von Hand Dateien kopieren und SVN selbst hat keine Ahnung davon, was ein Branch ist). Ich benutze Branches nicht sehr exzessiv, dafür umso mehr das Kommando „git stash“ (letzte Änderungen temporär zwischenspeichern und zurück zum letzten Commit), das letztlich intern mit Branches funktioniert.
• Es ist sicher: Da der komplette Commit-Baum eine kryptografisch signierte Kette bildet, kann ich sicherstellen, dass nicht jemand bei einem Servereinbruch bösartigen Code in meinen Programmcode eingeschleust hat.
• Viele moderne Quellcode-Verwaltungsseiten (etwa GitHub) unterstützen Git.

Darüber hinaus schließe ich mich Andreas an: Beiträge über andere VCS sind nicht verboten und erhöhen die Entscheidungsvielfalt. Ich habe im Übrigen nicht das Gefühl, dass Andreas Git als „allein selig machend“ vorgestellt hat, eher im Gegenteil.

Edit: Für Kommandozeilen-SVN-Benutzer empfehle ich als Einführung in Git http://git.or.cz/course/svn.html" target="_blank (auf Englisch), vor allem sieht man da, dass sich die Befehle nicht groß (und teilweise gar nicht) unterscheiden.

Grüße
Johannes

[BorisM]

Edit: Für Kommandozeilen-SVN-Benutzer empfehle ich als Einführung in Git http://git.or.cz/course/svn.html" target="_blank (auf Englisch), vor allem sieht man da, dass sich die Befehle nicht groß (und teilweise gar nicht) unterscheiden.

Danke, werde ich mir mal anschauen. Was für mich relevant ist ist aber dann vorallem ob man ein bestehenden SVN-Repository nach Github konvertiert bekäme. Da hab ich aber noch incht nachgeforscht ob das geht :-)

Edit: Scheint zu gehen laut http://john.albin.net/git/convert-subversion-to-git" target="_blank . Wenn ich mal mehr Zeit habe werde ich mir das wohl mal anschauen.

[Michael_Poschmann]

Hallo Johannes,

sofern "offline" als Vorteil gesehen wird - meine damalige Zusi2-Strecke erblickte in einer CVS-Umgebung das elektrische Licht der Welt. Diese wiederum war auf meinem Arbeitsplatzrechner installiert - auch nach dem Ziehen des magischen Steckers zum Internet konnte uneingeschränkt weitergearbeitet werden. Es scheint also mehrere Ansätze zu geben, die man in diese Richtung konfigurieren kann.

Die damalige Organisation meines Schaffens war allerdings eine andere als heute, zudem habe ich den Einzelkämpfermodus bereits lange hinter mir gelassen.

Gruß mit Diskussion-Deschawüh
Michael

[Roland Ziegler]

Es kommt halt immer auf die Aufgabenstellung an. Bei Git geht die Beherrschbarkeit für die vierte Dimension auf Kosten der dritten. Auch wenn man es kunstvoll verbrämt, Git-Branches sind de-facto ein ziemliches Kastrat, und für bestimmte Arbeitsweisen (meine), die hier Flexibilität fordern, ungeeignet. Die von Git angebotene Lösung, mit Submodulen zu arbeiten, ist doch eine sehr beschränkte, statische. Ich bezweifle nicht, dass es Projekte gibt, sich sich so hervorragend verwalten lassen. Meine jedoch nicht.

[Johannes]

Hallo Michael,

sofern "offline" als Vorteil gesehen wird - meine damalige Zusi2-Strecke erblickte in einer CVS-Umgebung das elektrische Licht der Welt. Diese wiederum war auf meinem Arbeitsplatzrechner installiert - auch nach dem Ziehen des magischen Steckers zum Internet konnte uneingeschränkt weitergearbeitet werden. Es scheint also mehrere Ansätze zu geben, die man in diese Richtung konfigurieren kann.

Da gebe ich dir Recht – mit dieser Arbeitsweise ist man bei CVS/SVN aber gleichzeitig auf den eigenen Rechner beschränkt, d.h. kann seine Änderungen nicht mit einem zentralen Server synchronisieren (zwecks Backup, Veröffentlichung oder gemeinsamer Arbeit). Für einfache Projekte von „Einzelkämpfern“ mag das aber unter Umständen eine sinnvolle Arbeitsweise sein.

Nach dem, was ich hier im Forum gehört habe, entstehen Zusi-3-Strecken viel eher in Teamarbeit (wobei es Ausnahmen geben mag) und benötigen deshalb einen zentralen Server zur Synchronisation.

Git (und verteilte VCS allgemein) kann man sich übrigens wie eine Erweiterung genau der beschriebenen Arbeitsweise vorstellen: Auf jedem beteiligten Rechner (egal ob Arbeitsplatzrechner, GitHub-Server oder anderer zentraler Server) ist eine Git-Installation vorhanden, die wie in deinem Beispiel komplett eigenständig lebensfähig ist.

Will man nun sein Projekt auf einem zentralen Server veröffentlichen, so ist dort einfach eine zweite solche Installation vorhanden, mit der man seine Änderungen synchronisiert. Ein „zentraler“ Server ist nur deshalb „zentral“, weil alle Beteiligten sich darauf einigen, alle ihre Änderungen mit diesem Server zu synchronieren.

Grüße
Johannes

(der im Übrigen niemanden zu Git „bekehren“ will – die Diskussion hier aber trotzdem ziemlich spannend findet =)

[Bernhard Raschke]

Hallo Andreas,

erst mal herzlichen Dank für Deine ausführlichen und herrlich locker geschriebenen Ausführungen zum Thema. Irgendwie scheine ich da ohne Absicht ziemlich was losgetreten zu haben, wenn ich mir die Reaktionen so anschaue. Mehr oder weniger hatte ich mich auf Oliver Lamms Tipps hin von TortoiseCVS überzeugen lassen, ohne die Vorteile wirklich zu begreifen oder gar zu nutzen. Ich werde den Thread jetzt erst mal verfolgen und versuchen, mir daraus eine Meinung zu bilden.

Aber nochmal: Vielen Dank für Deine Mühe!

[Roland Ziegler]

Gestern Abend hatte ich mal gesucht, wie groß denn der Nutzerkreis bei Git eigentlich tatsächlich sei, und war auf dieses hier gestoßen: http://jamesmckay.net/2012/03/what-is-g ... ket-share/. Es stammt von einem erklärten Git-Anhänger, der allerdings eingesteht, dass der Git-Hype abschreckend wirke - mein Reden.

Aber auch er tut genau dasselbe, verbreitet einseitige Propaganda:

It’s old-school, inefficient, restrictive, trunk-based tools like Subversion

Es macht Spaß, dergleichen zu zerpflücken:

"Old School": Wer bitte, definiert das? Git ist gerade mal zwei Jahre jünger als SVN und zudem auch nicht der Pionier verteilter Systeme. Die gab es schon vorher. Man erinnere sich: Git ist ja erst entstanden, als BitKeeper kommerzialisiert wurde und Herr Torvalds seine gewohnte Arbeitsumgebung von heute auf morgen verlor. Ich plädiere weiterhin für, aus den Anforderungen zu einer Lösung zu kommen und nicht für eine Lösung die Anforderungen zu suchen. Die Entwicklung von Git folgerte genau aus diesem Ansatz, für die Anforderungen eines bestimmten Projektes.

"Inefficient": Was ist an Nicht-Git Systemen ineffizient? Kann es sein, dass ihm da Erfahrung fehlt?

"Restrictive": Oder umgekehrt? Empfinden CVS/SVN-Nutzer das beschränkte Branching bei Git möglicherweise als restriktiv?

"trunk-based": Ist es nicht der Sinn eines Versionsmanagement-Systems, einen roten Faden durch eine Entwicklungsgeschichte zu weisen?

Ich rate zu mehr Vorsicht. Das gilt auch für in diesem Thread hier geäußerte vermeintliche Vorzüge von Git gegenüber allem anderen. Auch die könnten sich nämlich bei näherer Betrachtung nicht alle als standfest erweisen.

Zu den Zahlen: Das SVN zu den ganz Großen gehört, überrascht mich nicht. Dass es so dominierend sein soll aber doch. Nimmt man dazu, dass auch CVS weiterhin noch stark ist, könnte man vielleicht eine Erklärung finden.

Es gibt zwar Domänen in der Software-Industrie, die dreimal im Jahr neu aufgelegt werden, wenn man gerade wieder die nächste Sau durchs Dorf treibt, aber das Rückgrat unserer Software ist doch deutlich langlebiger, auf Jahre und mittlerweile auch auf Jahrzehnte ausgelegt. Da wechselt man auch das Versionsverwaltungssystem nicht einfach wie das Hemd, vor allen nicht, wenn man in bestimmten Trends keine wirklichen Vorteile erkennt. In der Unix-Welt ist eine typische Entwicklung ein Beginn mit RCS, ein Umstieg auf CVS und später und weiterhin anhaltend auf SVN. Die Umstiege waren verlustfrei, weil nämlich diese drei dieselbe Grundarchitektur aufweisen, meine ersten drei Dimensionen im gestrigen Beitrag. Bei einem Umstieg zu Git müsste man bei der Konvertierung Abstriche machen, aufgrund der Git-Beschränkung beim Branching. Die Historie mag vollständig übertragen werden, die Zugreifbarkeit auf die ursprünglichen Branches aber steht auf einem anderen Blatt. Wer das nicht braucht, aber durch Änderung der Entwicklungsstruktur heute größeren Wert auf integrierte Verteilbarkeit legt (die vierte Dimension), wird vielleicht eher zu einem Umstieg bereit sein.

Wie sieht denn das Leben in einem größeren Repository aus? Auch hier gilt, das es dabei ganz auf Stil und Gewohnheit einer Entwicklergruppe ankommt. Aber ein typisches Szenario ist dieses: Verschiedene Softwarebereiche, zunächst unabhängig entstanden, werden stärker miteinander verzahnt, teilweise umgegliedert, für bessere Wiederverwendung zu neuen Paketen geschnürt, aber stets mit funktionstüchtigem Ganzen. Selbstredend sind immer irgendwelche Branches aktiv, in zwei Kategorien, als sogenannte Feature- und Release-Branches, und alle enthalten immer nur Teile, und diese Teile wechseln alle paar Wochen oder noch häufiger. Natürlich gibt es Regeln, und es wird weiter von Mensch zu Mensch kommuniziert (mechanische Werkzeuge können Kommunikation nie ersetzen). Das ganze ist immer wieder in Bewegung, läuft dabei aber stabil, das Szenario wird gelebt und das über Jahre.

Herr Torvalds wird für die Entwicklungsstruktur seines Linux-Kerns vermutlich ein ziemlich anderes Szenario im Kopf gehabt haben, und dafür seine Lösung konzipiert. Das ist prima. Aber ob jetzt jeder Neueinsteiger dem Linux-Kern-Projekt nacheifern soll? Das merkwürdige ist, dass doch auch die CVS/SVN-Nutzer im Netz arbeiten. Warum vermissen die die Repository-Kaskade eigentlich nicht? Weil sie vielleicht für ihre Szenarien keine wichtige Rolle spielt?

[Jens Haupert]

Hallo Roland,

stimmte die voll und ganz zu bis auf folgenden Punkt:

"Inefficient": Was ist an Nicht-Git Systemen ineffizient? Kann es sein, dass ihm da Erfahrung fehlt?

Kann es sein, dass er Speicherbedarf anspricht?

Zumindest hier ist SVN nicht ganz das Gelbe vom Ei. Konvertiert man ein SVN nach Git verkleintert sich der lokale Platzbedarf (trotz der Tasache, dass nun ALLE Versionen und nicht nur die LETZTE Version auf der Platte liegen) in der Regel um den Faktor 3-10! Sehr beachtlich. Alle anderen "Vorteile" sind natürlich sehr subjektiv.

MfG Jens

[Roland Ziegler]

Wie ist das Git-Repository denn aufgebaut?

Das von SVN kenne ich naturgemäß ein wenig. Es ist eine ziemlich dynamische Mischung aus Text und Binär, alles als (unlesbarer) Text kodiert (in der Rep-Lösung als Dateisystem). Warum das so und nicht anders gemacht wird, hat nach Darstellung der Autoren sehr viel mit Effizienz zu tun.

[Johannes]

In der Unix-Welt ist eine typische Entwicklung ein Beginn mit RCS, ein Umstieg auf CVS und später und weiterhin anhaltend auf SVN.

Sowie in jüngster Zeit der Umstieg von SVN auf Git, den etliche der größten Open-Source-Projekte hinter sich gebracht haben (siehe unter http://de.wikipedia.org/wiki/Git#Verwendung" target="_blank).

Roland, worüber regst du dich denn so auf? Git wurde hier im Forum als ein VCS unter vielen vorgestellt und überhaupt nicht gehypt, geschweige denn als „Allheilmittel“ bezeichnet – im Gegenteil, Andreas hat einen allgemeinen und sehr ausgewogenen Beitrag über Versionskontrollsysteme geschrieben, in dem er sich nicht einmal konkret auf Git bezieht. Ein Git-Tutorial wird es deshalb, weil Andreas sich mit Git halt am besten auskennt. Wer tut es ihm nach und schreibt ein Tutorial über SVN?

Außerdem richtet sich das Tutorial explizit an VCS-Anfänger, von einem Umstieg existierender Projekte war eigentlich nur von deiner Seite die Rede.

Für dich ist SVN am besten geeignet, weil das Branch-Konzept da flexibler ist (kannst du mal ein Beispiel nennen, wo Git da versagt bzw. SVN besser ist? Mich würden die Nachteile des Git-Konzeptes da interessieren, speziell weil ich noch nicht so viel mit Branches arbeite).

Für mich ist Git besser geeignet, weil ich gern auch mal ohne Internetverbindung arbeite, aber trotzdem den vollen Funktionsumfang des VCS brauche. Weiter schätze ich die Möglichkeit, nur Teile von Dateien zu committen („git add -p“). SVN nutze ich für die Arbeit, wo die fehlende Internetverbindung nicht stört, weil ich per Remote Desktop arbeite und somit ohne Internet eh nicht arbeiten kann.

So hat jeder das VCS, das zu ihm passt. Und alle sind glücklich. Oder?

Grüße
Johannes

[Andreas Hänsch]

Ich kenne SVN nur als Anwender. Drei Konstrukteure laden ihre Daten auf einen Server und können den aktuellen Stand downloaden. Auch kann man schnell einmal einen alten Stand holen, wenn was schief läuft. Man muss aber explizipt absprechen wer was macht. Irgendwie funktioniert die Trennung nicht richtig. Und was das für einen Speicherplatz braucht, ist auch der Hammer. Man kann davon ausgehen, dass es auf dem lokalen Rechner der doppelte Platz ist. Beim Server weiß ich es nicht.

Ach ja, neuere SVN-Versionen areiten unter Windows 7 nicht mehr mit SolidWorks zusammen. Warum auch nicht. Mein Kollege konnte das Dialemma erst mit dem Downgrade auf V1.6 lösen.

Was so eine Software im privaten Sektor, oder wenn man alleine am Projekt arbeitet für einen Sinn macht, weiß ich nicht.

Andreas

[Roland Ziegler]

Sowie in jüngster Zeit der Umstieg von SVN auf Git, den etliche der größten Open-Source-Projekte hinter sich gebracht haben (siehe unter http://de.wikipedia.org/wiki/Git#Verwendung" target="_blank).

Und andere eben nicht. Und außerhalb der Open-Source-Welt? Siehe die genannten Zahlen zur Verbreitung.

Roland, worüber regst du dich denn so auf?

Du wirst es vermutlich ahnen, meine Beschäftigung mit Versionsverwaltung beschränkt sich nicht auf TransDEM & Co. Das bringt es dann einfach so mit sich, dass man auch unwillentlich immer wieder auf Git stößt, es häufig genug als Weltanschauung serviert bekommt, und eben selten von Leuten, die sich mit so etwas auskennen. Da es in letzter Zeit weniger wurde dachte ich, die Welle sei vorbei. Nun aber eben auch bei Zusi. Und der Thread-Titel kann, wenn man da entsprechend vorbelastet ist, durchaus ein wenig suggestiv und provokant wirken.

Wer das mit der religiösen Verklärung immer noch nicht glauben mag, schaue sich mal die wikipedia-Einträge zu Git an, vor allem den englischen.

Und da Git häufig genug in einem Atemzug mit Github genannt wird: Welcher sich mir nicht erschließen wollende Sinn verbirgt sich eigentlich dahinter, die Versionsgeschichte von Ein-Mann-Projekten im Internet zu veröffentlichen?

kannst du mal ein Beispiel nennen, wo Git da versagt bzw. SVN besser ist? Mich würden die Nachteile des Git-Konzeptes da interessieren, speziell weil ich noch nicht so viel mit Branches arbeite.

Sei versichert, Du wirst es auch nicht. Von Mini-Repositories und dediziert auf eine Aufgabenstellung beschränkten Projekten angesehen, wird vom Repository meist ein ziemlicher Kramladen verwaltet. Da ist eine Global-Branch, wie Git sie anbietet, wenig nutzbringend. Wenn Du Zugang zu größeren CVS/SVN-Repositories hast, schau mal nach, wie viele Branches es da auf Global-Level gibt. In meinem Bereich keine einzige. Man unterscheidet sogenannte Feature- und Release-Branches, wobei Feature-Branches erst mit SVN so richtig populär wurden, weil anders als bei CVS nach dem Merge die Versionsgeschichte der Branch erhalten bleibt.

Eine Feature-Branch wird angelegt, um in einem beliebigen Teilbereich neue Funktionalität zu entwickeln. Alles andere bleibt Trunk. Fortschritte dort werden vom Feature-Entwickler automatisch übernommen, umgekehrt Fortschritte beim Feature allerdings erst, wenn ein Zwischen- oder ein finales Merge gelaufen ist.

Eine Release-Branch ist der klassische Weg, Veröffentlichungen zu pflegen. Zu einem bestimmten Zeitpunkt wird eine Veröffentlichungsversion aus dem Trunk per Branch ausgekoppelt und dort dann weiter gepflegt, bis Support für die Release ausläuft. Liegen jetzt im heterogenen Repository mehrere Produktentwicklungen, wird klar, dass auch eine Release-Branch wieder nur einen Teil des Repositories umfassen wird.

Beide Ansätze schließen einander nicht aus und werden entsprechend auch gerne kombiniert. Wichtig und entscheidend sind die beliebig zusammensetzbaren Teilmengen für jede Branch.

Zur Inkompatibilität des Branch-Wesens siehe auch hier

CVS allows a branch or tag to be created from arbitrary combinations of source revisions from multiple source branches. It even allows file revisions that were never contemporaneous to be added to a single branch/tag. Git, on the other hand, only allows the full source tree, as it existed at some instant in the history, to be branched or tagged as a unit. Moreover, the ancestry of a git revision makes implications about the contents of that revision. This difference means that it is fundamentally impossible to represent an arbitrary CVS history in a git repository 100% faithfully.

RCS/CVS/SVN hier gleichzusetzen wegen gleicher Grundarchitektur aus Client-Sicht. Ob es in jedem Fall sinnvoll ist, Branches auf Ebene von einzelnen Dateien anzulegen, steht auf einem anderen Blatt.

SVN nutze ich für die Arbeit

Dann schau vielleicht mal etwas gründlicher hinein. Es könnte helfen, voreilige Schlüsse zu vermeiden.

Und was das für einen Speicherplatz braucht, ist auch der Hammer. Man kann davon ausgehen, dass es auf dem lokalen Rechner der doppelte Platz ist. Beim Server weiß ich es nicht.

Da hast Du vermutlich das gesamte Repository ausgecheckt, einschließlich aller Tags und Branches. Das führt dann, je nach Repository, in der Tat zu gewaltigem Speicherbedarf. Denn hierbei werden auf dem Client tatsächlich echte und komplette Kopien für jeden Branch- und Tag-Eintrag erzeugt, die auf dem Server lediglich als Verweis existieren.

Ach ja, neuere SVN-Versionen areiten unter Windows 7 nicht mehr mit SolidWorks zusammen. Warum auch nicht. Mein Kollege konnte das Dialemma erst mit dem Downgrade auf V1.6 lösen.

SVN 1.7 hat eine neue Verwaltungsstruktur für die Clientseite. Da häufig verschiedene SVN-Clients auf dieselbe Working Copy zugreifen, muss man prüfen, ob schon alle SVN 1.7 beherrschen.