Versionskontrolle für Data Science

Änderungen an Daten und Software nachverfolgen – von dir selbst oder von Mitwirkenden – ist in jedem Projekt entscheidend, ob Forschung, Data Science oder Softwareentwicklung. Eine bestimmte Version des gesamten Projekts referenzieren oder wiederherstellen zu können, verbessert die Reproduzierbarkeit: vor der Veröffentlichung, beim Beantworten von Reviewer-Kommentaren und beim Bereitstellen von Zusatzinformationen für Reviewer, Editorinnen und Leser.

Die besten Werkzeuge dafür sind Versionskontrollsysteme aus der Softwareentwicklung wie Git, Mercurial und Subversion. Sie zeichnen auf, wer wann was in einer Datei geändert hat, und synchronisieren Änderungen auf einen zentralen Server, sodass mehrere Beitragende am selben Dateisatz arbeiten können.

Auch wenn diese Tools das Nachverfolgen von Änderungen erleichtern, haben sie oft eine steile Lernkurve. Um sie zu überwinden, gibt es zwei Ansätze: eine systematische manuelle Methode zum Umgang mit Änderungen und die umfassende Nutzung von Versionskontrolle. Du kannst mit der ersten starten und schrittweise zur zweiten übergehen – oder direkt in die Versionskontrolle einsteigen.

Best Practices für Versionskontrolle

Unabhängig vom gewählten Ansatz solltest du einige grundlegende Empfehlungen berücksichtigen:

1. Sichere (fast) alles, was von Menschen erstellt wurde, sofort nach der Erstellung. Dazu gehören Skripte und Programme aller Art, Softwarepakete, von denen dein Projekt abhängt, und Dokumentation. Einige wenige Ausnahmen werden weiter unten erläutert.

2. Halte Änderungen klein. Jede Änderung sollte so überschaubar sein, dass die Änderungshistorie aussagekräftig bleibt. Eine einzelne Änderung wie Script-Datei überarbeiten, die mehrere hundert Zeilen hinzufügt oder ändert, ist vermutlich zu groß, weil sich damit Anpassungen an verschiedenen Teilen einer Analyse nicht getrennt nachvollziehen lassen. Umgekehrt sollten Änderungen nicht in zu viele Kleinteile zerlegt werden. Faustregel: Eine gute Größe ist ein Bündel von Anpassungen, das du dir vorstellen kannst, später in einem Schritt rückgängig zu machen.

3. Teile Änderungen häufig. Alle im Projekt sollten regelmäßig eigene Änderungen teilen und die der anderen einbinden. Lass die Versionen der einzelnen Personen nicht auseinanderlaufen, denn der Aufwand fürs Zusammenführen steigt überproportional mit der Differenz. Das gilt besonders für das unten beschriebene manuelle Vorgehen, das beim Mergen gleichzeitiger, potenziell konfliktträchtiger Änderungen keinerlei Unterstützung bietet.

4. Erstelle, pflege und nutze eine Checkliste zum Speichern und Teilen von Änderungen. Darauf gehören klare Commit-Nachrichten, die Größe und der Inhalt einzelner Änderungen, Stilrichtlinien für Code, das Aktualisieren von To-do-Listen sowie Verbote, halbfertige Arbeit oder kaputten Code zu committen.

5. Lege jedes Projekt in einem Ordner ab, der vom Arbeitsrechner gespiegelt wird – etwa per Dropbox – oder in einem entfernten Repository wie GitHub. Synchronisiere diesen Ordner mindestens täglich. Das kostet ein paar Minuten, spart dir aber im Fall von Diebstahl oder Festplattenausfall sofort enorm viel Zeit.

So gehst du bei manueller Versionierung vor

Der erste empfohlene Ansatz, bei dem alles von Hand geschieht, hat zwei Zusatzschritte.

Erstens: Lege im docs-Unterordner des Projekts eine Datei CHANGELOG.txt an und notiere dort datierte Einträge zu Änderungen in umgekehrt chronologischer Reihenfolge (also die neuesten zuerst). Diese Datei entspricht einem Laborbuch und sollte Einträge wie die folgenden enthalten.

## 2016-04-08

* Switched to cubic interpolation as default.
* Moved question about family's TB history to end of questionnaire.

## 2016-04-06

* Added option for cubic interpolation.
* Removed question about staph exposure (can be inferred from blood test results).

Zweitens: Kopiere das gesamte Projekt, sobald eine wesentliche Änderung vorgenommen wurde (also eine, die die Ergebnisse spürbar beeinflusst), und speichere diese Kopie in einem Unterordner mit Datumsnamen im synchronisierten Bereich. So ergibt sich eine Struktur wie unten:

.
|-- project_name
|   -- current
|       -- ...project content as described earlier...
|   -- 2016-03-01
|       -- ...content of 'current' on Mar 1, 2016
|   -- 2016-02-19
|       -- ...content of 'current' on Feb 19, 2016

Hier ist der Ordner project_name mit einem externen Speicher (z. B. Dropbox) verknüpft, in current wird gearbeitet, und die weiteren Unterordner in project_name sind frühere Stände.

Vor- und Nachteile der manuellen Versionierung

Oft hört man: „Storage ist billig, Zeit ist teuer“. Alles zu kopieren, wie oben vorgeschlagen, mag verschwenderisch wirken, da viele Dateien unverändert bleiben. Aber bedenke: Eine Terabyte-Festplatte kostet im Einzelhandel etwa 50 $, also kosten 50 GB weniger als 5 $. Solange große Datendateien vom Backup-Bereich ausgenommen werden (mehr dazu weiter unten), ist dieser Ansatz günstiger als die Zeit, die du bräuchtest, um Dateien per Hand auszuwählen.

Dieses manuelle Vorgehen erfüllt die oben genannten Anforderungen, ohne neue Tools einzuführen. Arbeiten jedoch mehrere Forschende am selben Projekt, müssen sie sich abstimmen, sodass nie mehr als eine Person gleichzeitig an denselben Dateien arbeitet. Sinnvoll kann es sein, pro Beitragendem eine eigene Changelog-Datei zu führen und diese bei jeder Sicherung zusammenzuführen.

Versionskontrollsysteme

Was beim manuellen Prozess vor allem gefragt ist, ist Selbstdisziplin. Die Tools unseres zweiten Ansatzes – den wir in unseren eigenen Projekten nutzen – beschleunigen nicht nur die manuellen Schritte, sondern automatisieren einige davon und erzwingen andere. So ist weniger Selbstdisziplin nötig, um verlässlichere Ergebnisse zu erzielen.

Welches Tool heute in der Forschung am weitesten verbreitet ist, ist schwer zu sagen, aber am meisten spricht man zweifellos über Git. Das liegt vor allem an GitHub, einer populären Hosting-Plattform, die die technische Infrastruktur für Zusammenarbeit via Git mit einer modernen Weboberfläche verbindet. GitHub ist für öffentliche und Open-Source-Projekte sowie für Nutzer in Wissenschaft und Non-Profit kostenlos. GitLab ist eine geschätzte Alternative, die manche bevorzugen, weil die GitLab-Plattform selbst frei und Open Source ist. Bitbucket bietet kostenloses Hosting für Git- und Mercurial-Repositories, hat jedoch deutlich weniger Nutzerinnen und Nutzer aus der Wissenschaft.

Was du nicht unter Versionskontrolle stellen solltest

Dateigrößen und -formate

Nicht alle Dateitypen profitieren gleichermaßen von Versionskontrolle. Besonders stark variiert der Nutzen je nach Größe und Format.

• Erstens: Der Dateivergleich in Versionskontrollsystemen ist für Klartextdateien wie Quellcode optimiert. Die Möglichkeit, sogenannte „Diffs“ zu sehen, ist normalerweise einer der größten Vorteile. Microsoft-Office-Dateien (wie .docx) oder andere Binärdateien – etwa PDFs – lassen sich zwar versionieren, spezifische Änderungen zwischen Versionen sind jedoch nicht sichtbar. Auch tabellarische Daten wie CSV lassen sich versionieren, aber schon das Ändern der Reihenfolge von Zeilen oder Spalten erzeugt riesige Diffs, selbst wenn sich die Daten nicht geändert haben.

• Zweitens: Rohdaten sollten sich nicht ändern und benötigen daher keine Versionsnachverfolgung. Auch Zwischenstände und andere Ergebnisse müssen nicht versioniert werden, wenn sie sich aus Rohdaten und Software reproduzieren lassen. Sind Daten und Ergebnisse jedoch klein, empfiehlt es sich, sie zur einfachen Zusammenarbeit und zum Vergleich zwischen Versionen dennoch zu versionieren.

• Drittens: Gängige Versionskontrollsysteme sind nicht für Dateien im Megabyte- bis Gigabyte-Bereich ausgelegt, daher sollten große Daten- oder Ergebnisdateien nicht eingecheckt werden. (Als grober Richtwert: Das Limit für einzelne Dateien auf GitHub liegt bei 100 MB.) Einige hybride Ansätze wie Git LFS legen Text-Metadaten unter Versionskontrolle ab und speichern große Daten extern auf einem Server, sind aber noch nicht so weit gereift, dass wir sie pauschal empfehlen würden.

Unbeabsichtigtes Teilen

Ein weiterer Fall, in dem Versionskontrolle nicht zu deinem Vorteil spielt, ist „unbeabsichtigtes Teilen“. Forschende, die mit rechtlich geschützten Daten arbeiten (z. B. medizinische Daten), sollten darauf achten, diese nicht in öffentliche Repositories zu stellen. Manche Einrichtungen stellen private Systeme bereit – frag bei deiner IT-Abteilung nach.

Außerdem solltest du keinesfalls Zugangsdaten wie Passwörter oder private Schlüssel in ein Versionskontrollsystem einchecken, wo andere darauf zugreifen könnten.

Wenn du das alles einmal ausprobieren möchtest, schau dir unsere kostenlose Einführung in Git für Data Science an.

Danksagung

Dieser Beitrag basiert auf „Good enough practices in scientific computing“ von Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt und Tracy K. Teal, https://doi.org/10.1371/journal.pcbi.1005510.