Seite 3: Best Practices

Inhaltsverzeichnis

Best Practices für DVCS

redView benötigt als Open-Source-Projekt ein öffentliches Repository, von dem sich jeder den Sourcecode auf seinen Rechner klonen kann. Jeder Committer darf direkt in das Remote-Repository seinen Code "pushen" – in anderen Projekten ist es denkbar, dass das erst ein Koordinator prüft, der die Änderung dann an das öffentliche Repository sendet – oder wie im Falle von eclipse.org, wo alles erst durch Gerrit laufen muss.

Zunächst war das öffentliche Repository nur auf SourceForge gehostet – aber wie es der Zufall will: An wichtigen Tagen führte SourceForge Wartungsarbeiten aus, der Server war nicht erreichbar und die Kommunikation zwischen den Entwicklern über das öffentliche Repository war über einige Stunden oder länger nicht möglich.

Seitdem pflegt das Projektteam drei öffentliche Repositories: bei SourceForge, Bitbucket und Eclipse Labs. Jeder Anwender kann sich daher auch das Repository auswählen, in dessen Umgebung er sich auskennt oder wo er bereits einen Account hat. Der Master ist derzeit bei SourceForge, und die beiden anderen sind nur Replikate. Fällt aber SourceForge aus, bekommt eines der beiden anderen die "Master"-Rolle. Das hat sich über die letzten Monate bewährt – und es erfordert nur zwei weitere Push-Kommandos an die Remote Repositories.

Verteilte Versionskontrollsysteme bieten einen weiteren, nicht zu unterschätzenden Vorteil: Das Arbeiten mit Verzweigungen (Branches) ist einfach. Während Branches unter CVS/SVN immer zentral am (einzigen) zentralen Repository liegen, lassen sich bei DVCS Verzweigungen von jedem Entwickler lokal pflegen. In manchen Projekten wird für das Bearbeiten eines einzelnen Bugs ein neuer Branch angelegt, weil es so einfach ist.

Der (lokale) Entwickler entscheidet, wann er einen Branch an den Server sendet, und auch, was von seinen einzelnen commit-Vorgängen an den Server geht. Häufig probiert man Sachen aus, möchte aber nicht, dass jeder im Team alle 'Versuche' sieht – dafür gibt es den rebase-Befehl.

Dieser erlaubt es, mehrere experimentelle commit-Vorgänge eines Branch durch einen veröffentlichungswürdigen neuen Commit zu ersetzen. Wichtig ist, niemals rebase an einem schon angeschobenen oder von anderen mit pull bezogenen Branch durchzuführen, da rebase die History verändert: Das ist nur lokal in eigenen unveröffentlichten Branches erlaubt.

In Open-Source-Projekten möchte man es den Nutzern des Projekts so einfach wie möglich machen, Fehler zu beheben und diese dem Projekt zur Verfügung zu stellen. Andererseits bekommen Entwickler erst Committer-Status – und damit Schreibrechte –, wenn sie sich bewährt haben. Unter CVS wird in dem Fall ein Patch erstellt, der einem Committer gesendet wird oder an einem Bug hängt. Das Verfahren ist umständlich, und wenn die Bearbeitung längere Zeit in Anspruch nimmt, "passt" der Patch nicht mehr. Mit einem DVCS wie Mercurial geht das einfach: Wer etwas einreichen möchte, erstellt unter Mercurial einen serverseitigen Klon beziehungsweise unter Git einen Fork. Hier nun zwei Beispiele von eclipselabs.org (Mercurial-Klon) und GitHub (Git-Fork):

Mit einem Klick erstellt man den Klon/Fork am Server. Jetzt kann dessen "Owner" mit dem Repository arbeiten, da er ja einen schreibenden Zugriff auf sein "eigenes" Repository hat. Wenn die Aufgabe gelöst ist, teilt er das einem Committer mit, der sich dann die Änderungen mit pull von dem Repository holen kann. Einfacher geht es nicht mehr.