Versionierung bewahrt Bedeutung, nicht nur Kopien
Viele Projektordner enthalten zahlreiche Dateien, aber keine belastbare Geschichte. Namen wie final_neu_wirklich.xlsx verraten weder Ursprung noch Bearbeitung. Gute Versionierung beantwortet drei Fragen: Welche Fassung war die Eingabe? Was wurde verändert und warum? Welche Fassung erzeugte die Zahl oder Abbildung in der Arbeit? Dafür braucht es einen unveränderten Rohstand, bewusst benannte Meilensteine und einen kurzen Änderungsnachweis.
Nicht jeder Speichervorgang muss eine neue veröffentlichte Version werden. Unterscheide automatische Bearbeitungshistorie, tägliche Arbeitsstände und fachliche Releases. Ein fachlicher Release ist sinnvoll, wenn sich Variablen, Ausschlüsse, Kodierungen, Analyseentscheidungen oder berichtete Ergebnisse ändern. Diese Stände bleiben schreibgeschützt oder werden durch Prüfsummen abgesichert. Synchronisationsverlauf und Backup ergänzen dieses System, ersetzen aber keine verständliche Kennzeichnung. Halte zusätzlich fest, wer einen Release geprüft und freigegeben hat; dadurch wird aus der Dateifolge ein verantworteter, auch für Dritte verständlicher Forschungsnachweis.
Ein Dateiname sollte ohne Öffnen lesbar sein
Nutze wenige, feste Bausteine in gleicher Reihenfolge: Projektkürzel, Inhalt, Status, Datum im Format JJJJ-MM-TT und Versionsnummer. Vermeide Leerzeichen, Sonderzeichen und personenbezogene Angaben. Ein Beispiel lautet lernwege_umfrage_clean_2026-08-22_v03.csv. Der Begriff clean ist nur sinnvoll, wenn ein Bereinigungsprotokoll erklärt, was geschehen ist. Bezeichnungen wie raw, interim, clean und release sollten im Projekt einmal definiert werden.
Datumsangabe und Versionsnummer leisten Unterschiedliches. Das Datum ordnet einen Stand zeitlich ein, die Nummer zeigt eine geplante Folge. Beginne nicht bei jeder kleinen Korrektur eine neue Benennungslogik. Bei mehreren Bearbeitenden darf nur ein vereinbarter Ort die maßgebliche Fassung enthalten. Initialen im Dateinamen können kurzfristig helfen, sind aber kein Ersatz für Rollen und ein zentrales Änderungsprotokoll.
Vom Ergebnis rückwärts durch die Analysekette
Eine reproduzierbare Kette verbindet Bericht, Abbildung oder Tabelle mit Skript, Softwareumgebung, bereinigtem Datenstand und unveränderter Quelle. Vergib Ausgaben eindeutige Namen und notiere im Analyseprotokoll, welcher Befehl welche Eingaben verwendete. Bei manuellen Programmen werden relevante Filter, Tabellenblätter, Pivot-Stände und Exportoptionen festgehalten. Ein Screenshot kann ergänzen, aber keine textliche Entscheidungskette ersetzen.
Prüfe die Kette rückwärts: Öffne eine Zahl in der Arbeit, finde die Ergebnisdatei, den Erzeugungsschritt und die konkrete Eingabe. Danach gehe vorwärts von Rohdaten zu Ergebnis und achte auf nicht dokumentierte Zwischenkopien. Wenn ein Schritt nicht rekonstruiert werden kann, ist die Lücke zu beschreiben und künftig zu schließen; ein nachträglich erfundener Ablauf wäre irreführend.
Git, Tabellen und Cloud-Historien sinnvoll einsetzen
Textbasierte Skripte und Dokumentation lassen sich gut mit Git versionieren. Commits sollten kleine, sinnvolle Änderungen und verständliche Nachrichten enthalten. Große Binär- oder sensible Forschungsdaten gehören jedoch nicht ungeprüft in öffentliche Repositorys. Nutze dafür geeignete institutionelle Speicher oder Datenversionswerkzeuge und halte im Code lediglich zulässige Identifikatoren und Bezugswege fest.
Für Tabellenkalkulationen ist ein manuelles Versionslog besonders wichtig, weil Formeln, Filter und direkte Wertänderungen zugleich wirken können. Exportiere freigegebene Zwischenstände in ein geeignetes Format und dokumentiere weiterhin die Ursprungsdatei. Eine Cloud-Historie erleichtert die Wiederherstellung, doch ihr Aufbewahrungszeitraum und ihre Exportierbarkeit können begrenzt sein. Teste, ob du eine frühere Fassung tatsächlich öffnen und einordnen kannst.
Was nicht in einen Versionsnamen gehört
Vermeide Bewertungen wie „richtig“, „schön“ oder „endgültig“. Sie altern schlecht und erklären keine Änderung. Sensible Kategorien, Klarnamen, Diagnosen oder Teilnehmerkennungen dürfen nicht aus Bequemlichkeit in Dateinamen erscheinen, weil Namen oft in Backups, Benachrichtigungen und Freigabelisten sichtbar werden. Notiere den Schutzstatus in einem kontrollierten Inventar.
Ändere Dateinamen nicht losgelöst von Verweisen in Skripten und Dokumentation. Wenn ein Release umbenannt wird, protokolliere alten und neuen Namen. Automatisch erzeugte Zeitstempel können nützlich sein, ersetzen aber nicht die fachliche Version und den Grund der Änderung.
Der Versionsaudit vor der Ergebnisfreigabe
- Ist der ursprüngliche Datenstand unverändert und gegen versehentliches Überschreiben geschützt?
- Gibt es genau eine als maßgeblich bezeichnete Arbeits- oder Releasefassung?
- Erklärt das Log jede fachlich relevante Transformation mit Grund und Nachweis?
- Verweisen Tabellen und Abbildungen auf die tatsächlich verwendete Eingabe und Softwareversion?
- Lässt sich ein älterer Stand aus Backup oder Archiv wiederherstellen und interpretieren?