Versionskontrolle bei der Dateifreigabe: Überschreiben vermeiden

Überschreib-Chaos lässt sich mit drei zusammenwirkenden Werkzeugen beenden: native Versionshistorie auf der Sync-Plattform (Google Drive behält 100 Versionen oder 30 Tage, Dropbox Business 180 Tage, OneDrive 500 Versionen), Check-in/Check-out-Sperren für Dateien, die nur eine Person gleichzeitig bearbeiten sollte (SharePoint, Box oder DAMs wie Bynder), und Git oder Git-LFS für alles Textbasierte. Eine Namenskonvention mit vNN-Suffixen darüber schichten, und man erhält sowohl automatische Wiederherstellung (Sync-Tool) als auch absichtliche Schnappschüsse (Git-ähnliche Branches).

Die drei Versagensmuster geteilter Dateien

Jede Überschreib-Katastrophe ist eines von drei Mustern. Sie erkennen, macht die Fixes offensichtlich.

Gleichzeitige Speicher-Kollision: Zwei Personen bearbeiten dieselbe Datei gleichzeitig; letzte-Speicherung-gewinnt, die Arbeit der ersten verschwindet. Fixes: Echtzeit-Co-Authoring (Google Docs, Office Online) oder explizite Sperrung (SharePoint Checkout).
Versehentliches Überschreiben: Jemand öffnet "die Datei", bearbeitet sie, speichert über die kanonische Kopie während er beabsichtigte, eine persönliche Arbeitskopie zu speichern. Fix: klare Quellenwahrheits-Trennung mit schreibgeschützten kanonischen Kopien.
Verlorene History: Eine Datei war vor drei Versionen korrekt, aber der aktuelle Zustand ist kaputt und niemand kann die Zwischenschritte rekonstruieren. Fix: behaltene Versionshistorie auf der Plattform plus disziplinierte Schnappschüsse.

Echtzeit-Co-Authoring für lebende Dokumente

Für Prosa und Tabellen, die viele Leute bearbeiten, eliminiert Echtzeit-Co-Authoring Überschreib-Kollisionen vollständig. Google Docs, Sheets und Slides handhaben 100+ gleichzeitige Editoren ohne Drama. Microsoft 365 Word Online und Excel Online sind in der Parität dahinter, mit besserer Legacy-.docx-Wiedergabetreue.

Notion, Coda und Airtable erweitern das auf strukturierte Dokumente und Datenbanken. Figma macht dasselbe für Design-Dateien.

Bei der Tool-Wahl das Echtzeit-Co-Authoring mit tatsächlichen Dateigrößen prüfen. Einige Tools verschlechtern sich über 1.000 Zeilen oder 50 Seiten hinaus.

Check-in/Check-out-Sperrung für Binärdateien

Binäre Dateien – PSDs, Illustrator-.ai, InDesign-.indd, Revit-.rvt, Premiere-.prproj, AutoCAD-.dwg – können Konflikte nicht sauber zusammenführen. Zwei Personen editieren bedeutet, die Änderungen einer Person sterben. Explizite Sperrung ist die Antwort.

Tools mit ausgereiftem Check-in/Check-out:

SharePoint: natives Check-in/Check-out auf jeder Bibliothek. Untergenutzt aber felsenfest.
Box: Dateisperrung mit einem "Wer hat sie ausgecheckt?"-Indikator
Bynder, Frontify, Brandfolder: DAMs mit eingebauter Sperrung für kreative Assets
Perforce Helix Core: der Goldstandard für Game-Studios und VFX-Häuser

Git und Git-LFS für alles Textbasierte

Git ist der Goldstandard der Versionskontrolle. Verwenden für:

Quellcode (offensichtlich)
Markdown-basierte Dokumente, Wikis und interne Wissensdatenbanken
Konfigurationsdateien (Kubernetes YAML, Terraform, Ansible)
Datenschemata (Prisma, dbt-Modelle, SQL-Migrationen)
Alles, worauf man explizite Branching, Diffs und Code-Review möchte

Git-LFS erweitert Git auf große Binär-Assets. Es speichert die binären Blobs auf einem separaten Server und Git verfolgt Zeiger. GitHubs Git-LFS ist kostenlos bis zu 1 GB Speicher und 1 GB Bandbreite monatlich; Datenpakete für je 5 $/Monat fügen je 50 GB hinzu.

Native Versionshistorie: Das Sicherheitsnetz

Jedes große Sync-Tool behält Versionshistorie automatisch. Die Standardwerte kennen:

Google Drive: 100 Versionen oder 30 Tage, je nachdem was später eintritt. Workspace-Pläne erweitern auf 100 Versionen ohne Zeitlimit bei Nicht-Google-Formaten.
OneDrive und SharePoint: standardmäßig 500 Versionen, konfigurierbar pro Bibliothek
Dropbox: 30 Tage bei Basic, 180 Tage bei Business, 365 Tage bei Advanced, unbegrenzt bei Enterprise
Box: 100 Versionen bei Business, unbegrenzt bei Enterprise
Apple iCloud Drive: nur 30 Tage; das schwächste der Großen

Den tatsächlichen Tier verifizieren. Manche Organisationen entdecken in einer Krise, dass der Admin die Aufbewahrung vor zwei Jahren zur Speichereinsparung reduziert hatte.

Namenskonventionen als explizite Schnappschüsse

Automatische Versionshistorie ist hervorragend für kleine Wiederherstellungen. Für Projektmeilensteine sind explizite benannte Schnappschüsse klarer. Die vNN-Konvention in Dateinamen gibt zeitpunktbezogene Schnappschüsse, die Menschen navigieren können:

2026-06-12_ACME-RB_spec_v01.pdf
2026-06-15_ACME-RB_spec_v02.pdf
2026-06-19_ACME-RB_spec_v03.pdf

Wenn jemand fragt "Was haben wir am 15. Juni an den Kunden geschickt?", kann man antworten, ohne durch Versionshistorie-Metadaten zu graben.

Rollback-Übungen beweisen, dass das System funktioniert

Ein Backup, das man nie testet, ist kein Backup. Dasselbe gilt für Versionshistorie. Einmal im Quartal eine zufällige Datei nehmen, behaupten, sie sei gestern beschädigt worden, und messen, wie lange es dauert, die vorherige Version wiederherzustellen. Wenn es über 10 Minuten dauert, ist etwas kaputt – vielleicht ist die Sync-Tool-Aufbewahrung kürzer als gedacht, vielleicht weiß niemand, wo die History-Benutzeroberfläche ist.

Versionierte Dateien extern liefern

Wenn eine Version an einen Kunden muss – eine bestimmte Hauptversion, die er überprüft, nicht die laufende Arbeit – sie über einen Transferkanal senden, nicht als Sync-Link. Linkbasiertes Sharing aus dem Sync-Tool riskiert, dem Kunden eine Live-Bearbeitungsversion zu zeigen, die sich unter ihm verschiebt.

Ein Transferlink erfasst die Datei in einem Moment und liefert sie. Dienste wie HexaTransfer, Dropbox Transfer und Smash frieren den Zustand zum Sendezeitpunkt ein. Der Kunde sieht genau das, was gesendet wurde, bis der Link abläuft.

Jetzt kostenlos ausprobieren: https://hexatransfer.com – kein Konto erforderlich, bis zu 10 GB pro Transfer.