Subversives Git

Letzte Änderung am 24. Februar 2022 by Christoph Jüngling

Quellcodeverwaltung ist hilfreich, sinnvoll oder notwendig, je nach Sichtweise der Entwickler. Oft genug trifft auch alles gleichermaßen zu. Doch die Frage, welche Quellcodeverwaltung Verwendung finden soll, ist oft gar nicht so einfach zu beantworten.

Gerade neulich war ich bedauerlicherweise Teil einer Diskussion, in der ein Kollege die Ansicht vertrat, SVN sei besser als Git. Nun, seine Meinung lasse ich ihm gern. Ich sehe es genau umgekehrt, was er leider nicht akzeptieren wollte. In einem Team muss man sich aber auf ein System festlegen, um den Quellcode an einer zentralen Stelle zusammenzuführen. Da kann halt nicht jeder mit etwas anderem arbeiten. Aber halt, ist das wirklich so? In diesem Artikel will ich zeigen, dass Git und SVN (Subversion) durchaus sehr gut zusammenarbeiten können. Der Artikel Git und die Team Foundation zeigt, dass dies dort ebenfalls gilt.

Unterschiede

Der Kollege argumentierte, der einzige Vorteil von Git gegenüber SVN sei doch, dass man mit Git verteilt arbeiten könne. Da das in diesem Team ohnehin niemand tun würde, könne man genauso gut SVN verwenden. Das ist in gewisser Weise richtig, das tun wir in diesem Projekt nicht in dem Maße, wie es z.B. Open-Source-Entwicklerteams tun. Davon abgesehen ist es keineswegs der einzige Vorteil einer verteilten Quellcodeverwaltung, dass sie verteilt ist. Das ist nur der Anfang, damit beginnt der Spaß erst.

Außerdem, so der Kollege weiter, könne SVN besser mit dem verwendeten ALM-System “Polarion” zusammenarbeiten. Auch damit hat er leider recht. Das Git-Plugin wertet nur den “master”-Branch aus, was einigermaßen … “beschränkt” ist. Wer um Himmels Willen denkt sich so etwas aus? Aus diesen beiden Aspekten nun aber abzuleiten, welches System besser ist, erscheint mir etwas zu kurz gegriffen.

Solche Diskussionen gibt es branchenübergreifend öfter, mögen sie nun “Windows/Linux” oder “Nikon/Canon” betreffen. Oft genug ist es nur ein persönlicher Geschmack ohne sachlichen Hintergrund. Man kennt halt System X, und was man kennt (d.h. womit man Routine hat), das hält man für gut. Solange es nur eine Person betrifft, ist das auch völlig in Ordnung. Ob ich in meinem privaten Projekt mit Git, Mercurial, Subversion oder CVS arbeite, ist meine Sache. Doch wie sieht es im Team aus?

Policy vs. procedure

Ein wesentliches Ziel von Quellcodeverwaltung – wenngleich nicht das einzige – ist, dass der Programmcode eines Projektes an einer zentralen Stelle zusammengeführt wird. Diese Stelle ist dann gewissermaßen der SPOT (“single point of truth”). Jede Weiterentwicklung basiert auf dem Code in diesem zentralen Repository. Ein zentralisiertes Quellcodeverwaltungssystem wie SVN eignet sich natürlich gut dafür, was sicher der Grund ist, weshalb so etwas häufig favorisiert wird. Allerdings besteht auch bei dezentralen Systemen die Möglichkeit, ein Repository als das Haupt-Repository zu deklarieren und im Zweifelsfall immer davon abzuleiten. Was bei SVN also systemimmanent ist und immer so bleiben muss, ist bei Git, Mercurial und anderen dezentralen Systemen ebenfalls möglich, aber nicht zwingend. Policy (Git) vs. procedure (SVN).

Wenn die Firma oder das Team nun aber entschieden hat, Subversion zu verwenden, was nun?

Teamwork

Git bietet die Möglichkeit an, bei Bedarf mit dem entfernten Subversion-Repository zu kommunizieren. Auch mit Mercurial ist dies möglich, hierzu wird jedoch ein Plugin benötigt. Git kann dies bereits von Hause aus.

Um ein SVN-Repository mit Git lokal zu bearbeiten muss es zunächst (wie bei Git auch) geclont werden. Mit TortoiseGit ist das durch einen einfachen Zusatzhaken möglich. Auf der Kommandozeile benötigt man ebenfalls nur das zusätzliche Kommando „svn“, ansonsten unterscheidet es sich nicht:

git svn clone https://quelle-der-weisheit.com/projektname

Für die Aktualisierung von Änderungen, die andere Kollegen auf den SVN-Server hochgeladen haben:

Kommandozeile: git svn fetch

Es wird übrigens empfohlen, nach einem git svn fetch einen “Rebase” zu machen, also die lokalen Änderungen auf die neu geholten Änderungen aus dem SVN draufzusetzen, und keinen Merge zu machen!

Der “Push” von Git oder Mercurial heißt dann bei SVN “DCommit” (für “distributed commit”). Wie die Hilfe beschreibt, erzeugt dieser für jeden Commit in Git einen zugehörigen Commit in SVN.

Na super, dann sind wir uns ja einig: Ich nehme Git, und ihr könnt meinetwegen SVN nehmen.

UPDATE: Textliche Korrektur.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

9 + 3 =