Für und wider Git – versionierte Sicherung für das Familienarchiv

Veröffentlicht am 12. Juli 2026 · zuletzt aktualisiert am 10. September 2026 / in Digitale Archive

Ein privates Familienarchiv wächst über viele Jahre. Texte werden ergänzt, Aussagen korrigiert, Quellen neu bewertet und Zusammenhänge später anders eingeordnet.

Irgendwann entsteht deshalb nicht nur die Frage, wie eine Datei heute aussieht, sondern auch:

Warum habe ich das damals geändert?

Eine Datensicherung kann eine verlorene Datei zurückbringen. Sie erklärt aber nicht automatisch, wann und aus welchem fachlichen Grund sich eine Biografie, Quellenbewertung oder Personenzuordnung verändert hat.

Genau für diese Aufgabe nutze ich inzwischen Git – nicht überall, sondern gezielt für mein Familienarchiv.

Kurz gesagt

Git wird nicht zum allgemeinen Archivsystem und ersetzt kein Backup.

Der Obsidian-Vault bleibt der Arbeitsbestand in iCloud. Git liegt ausschließlich auf dem NAS und hält dort automatisch versionierte Sicherungsstände fest.

iCloud-Vault
= Arbeitsbestand für Windows, iPad und iPhone

NAS-Git-Repository
= versionierte Sicherung und Änderungsverlauf

Für Website und allgemeines Wissensarchiv wird Git weiterhin nicht eingesetzt.

Was Git überhaupt ist

Git kannte ich vor dieser Entscheidung nicht aus eigener Praxis. Vereinfacht gesagt ist es ein Änderungsprotokoll für Dateien.

Ein sinnvoller Arbeitsstand wird bewusst als Commit gespeichert. Jeder Commit erhält eine kurze Beschreibung. Die Gesamtheit dieser Arbeitsstände bildet das Repository.

Damit lässt sich später nachvollziehen:

• welche Dateien hinzugekommen, geändert oder entfernt worden sind,
• wann ein Stand festgehalten wurde,
• wie ein Text vorher aussah,
• warum eine Änderung vorgenommen wurde.

Bei Textdateien kann Git einzelne geänderte Zeilen gegenüberstellen. Bei Fotos, Scans oder PDFs erkennt es zwar eine geänderte Datei, kann deren inhaltlichen Unterschied aber normalerweise nicht verständlich darstellen.

Git ist damit weder Schreibprogramm noch Cloud noch vollständige Backup-Strategie. In dieser Architektur hält es automatisch zeitlich benannte Sicherungsstände fest; fachliche Entwicklungsgründe werden weiterhin separat dokumentiert.

Ein wachsendes Familienarchiv braucht ein Gedächtnis

Ein privates Familienarchiv ist niemals endgültig abgeschlossen. Neue Urkunden tauchen auf, Namen werden korrigiert, Zusammenhänge neu bewertet und bereits geschriebene Familiengeschichten ergänzt.

Die Änderungen erfolgen nicht nach einem festen Redaktionsplan. Manchmal wird über Wochen intensiv gearbeitet, danach bleibt der Bestand für Monate unverändert. Ergänzungen entstehen oft spontan, wenn neue Unterlagen eintreffen oder ein bisher unbeachteter Zusammenhang erkannt wird.

Eine ältere Dateifassung zeigt zwar, wie ein Text früher aussah. Sie erklärt aber nicht unbedingt, weshalb er verändert wurde.

Git kann diese Entwicklung nachvollziehbar machen. Fachlich sinnvolle Arbeitsstände erhalten Beschreibungen wie:

• Heiratsdatum nach Auswertung der Originalurkunde korrigiert
• Ortszuordnung aufgrund eines Kirchenbucheintrags geändert
• ungesicherte Familienüberlieferung aus der Biografie entfernt
• neue Quelle zur Linie Kühn aufgenommen
• Kapitel nach neuer chronologischer Erkenntnis umgestellt
• doppelte Personenzuordnung aufgelöst

Damit entsteht neben der Familienchronik ein zweites Gedächtnis: die dokumentierte Entstehungsgeschichte des Archivs.

Das Familienarchiv erinnert sich nicht nur an frühere Fassungen, sondern auch an die Gründe seiner Entwicklung.

Warum aus dem früheren Nein ein gezieltes Ja wurde

Meine ursprünglichen Einwände bleiben berechtigt:

• Git ist kein Backup.
• Große Binärdateien lassen sich kaum sinnvoll vergleichen.
• Repositorys können erheblich wachsen.
• Git-Verwaltungsdaten innerhalb eines Cloud-Ordners können Konflikte verursachen.
• Die Bedienung setzt eigenes Wissen voraus.

Entscheidend war eine präzisere Fragestellung. Git muss nicht jedes Problem eines digitalen Archivs lösen. Es genügt, wenn es eine konkrete Aufgabe besser erfüllt als die bisherige Struktur.

Bei meinem Familienarchiv ist diese Aufgabe klar: Fachliche Änderungen an Chroniken, Personenakten, Quellenlisten und Transkriptionen sollen als begründete Entwicklung nachvollziehbar bleiben.

Meine Entscheidung lautet deshalb nicht „Git überall“, sondern:

Git dort einsetzen, wo eine verständliche Änderungshistorie einen dauerhaften fachlichen Nutzen bietet.

Die tatsächliche Architektur

Die drei technischen Ebenen sind bewusst getrennt:

Der iCloud-Vault enthält keinen .git-Ordner und keinen Verweis auf eine entfernte Git-Datenbank. Dadurch werden die zahlreichen internen Git-Dateien nicht über iCloud zwischen mehreren Geräten synchronisiert.

Die Sicherungsroutine liest den lokalen iCloud-Stand ausschließlich aus. Git-Index, Objekte, Protokoll und Historie liegen auf dem NAS. Der Arbeitsrechner ist damit kein zweiter Git-Arbeitsbestand und der Sicherungsmechanismus schreibt niemals automatisch in den Vault zurück.

Binärdateien und Git LFS

Das Familienarchiv ist kein reines Textprojekt. Bei der Einrichtung umfasste es rund 9,23 GiB und enthielt neben Markdown unter anderem PDF-, TIFF-, DNG-, JPEG-, PNG-, XMP- und GEDCOM-Dateien.

Der erste Commit erfasste bewusst den vollständigen kontrollierten Ausgangsbestand. Das NAS-Repository belegte anschließend rund 8,62 GiB.

Damit ist der dokumentierte Initialstand vollständig. Die Grenze bleibt jedoch deutlich: Ändert sich eine große Binärdatei, kann Git eine weitere vollständige Fassung speichern. Neue große Bestände werden deshalb vor einem Commit bewusst geprüft.

Git LFS könnte große Dateien in einen gesonderten Objektspeicher auslagern. Es würde aber eine zusätzliche Speicher-, Sicherungs- und Wiederherstellungsebene schaffen. Deshalb wird es derzeit nicht eingesetzt.

Der Hauptnutzen von Git liegt weiterhin bei Text, Struktur und Metadaten. Bei Binärdateien hält es vor allem den damaligen Zustand fest.

Was die automatische Historie leistet

Die Sicherung läuft alle 30 Minuten im angemeldeten Benutzerkontext. Sie wartet nach einer Änderung mindestens fünf Minuten, damit kein noch bewegter iCloud-Zwischenstand festgeschrieben wird. Nur wenn sich etwas verändert hat, entsteht ein neuer Sicherungsstand auf dem NAS.

Damit lässt sich später zuverlässig klären:

• Welche Datei wurde geändert, hinzugefügt, verschoben oder gelöscht?
• Wann war sie noch vorhanden oder hatte einen anderen Inhalt?
• Welche frühere Fassung lässt sich gezielt ansehen oder wiederherstellen?

Bei einer Löschung bewahrt Git die frühere Fassung in den bereits vorhandenen Commits. Sie verschwindet also nicht aus der Historie, nur weil sie im Arbeitsbestand nicht mehr sichtbar ist.

Automatische Commits beantworten jedoch nicht zuverlässig die Frage, warum sich ein Familienarchiv geändert hat. Ein Zeitstempel wie „Automatische Sicherung“ ist ein technischer Nachweis, keine quellenkritische Begründung. Solche Gründe gehören weiterhin in die Personenakte, Quellenakte, Chronik oder einen nachvollziehbaren Änderungsvermerk.

Der regelmäßige Ablauf lautet:

Im iCloud-Vault arbeiten
→ iCloud-Synchronisierung abwarten
→ Sicherungsroutine erkennt einen ruhigen, geänderten Stand
→ NAS erzeugt einen versionierten Sicherungs-Commit
→ bei Bedarf frühere Fassung gezielt prüfen oder wiederherstellen

Flüchtige Obsidian-Arbeitszustände, temporäre Dateien, iCloud-Platzhalter und Konfliktkopien werden nicht als historische Archivänderungen gesichert. Große neue Binärdateien bleiben sichtbar und werden als Zustand gesichert, benötigen aber wegen ihrer Größe weiterhin Aufmerksamkeit.

Abgrenzung: Git, Arbeitscache und Backup

Die drei Verfahren lösen unterschiedliche Aufgaben:

Das NAS-Repository schützt die Git-Historie vor dem einfachen Verlust des Arbeitsrechners. Es schützt aber nicht allein vor NAS-Ausfall, Schadsoftware, Brand, Diebstahl oder einer Beschädigung des Repositorys. Deshalb bleibt eine unabhängige Datensicherung erforderlich.

Frühere committed Fassungen können gezielt wiederhergestellt werden. Nicht festgeschriebene Änderungen gehören dagegen noch nicht zur Git-Historie.

Der Codex-Arbeitscache vermeidet wiederholte technische Analysen bei der Website-Arbeit. Er ist weder Versionsverwaltung noch Backup.

Governance und Übergabefähigkeit

Git darf den Bestand nicht unverständlich machen. Deshalb gelten folgende Regeln:

• Der sichtbare iCloud-Vault bleibt unabhängig von Git lesbar.
• Markdown bleibt auch ohne Obsidian verständlich.
• Die Rollen der drei Speicherorte sind dokumentiert.
• Platzhalter, Konfliktkopien und temporäre Dateien werden ausgeschlossen.
• Große neue Binärdateien werden vor einem Commit geprüft.
• Automatische Sicherungsstände sind zeitlich nachvollziehbar; fachliche Gründe werden in den Archivunterlagen festgehalten.
• Komplexe Branch-Modelle und Git LFS werden vermieden.
• Das NAS-Repository gehört zur regulären Sicherungsstrategie.
• Die Wiederherstellung muss dokumentiert und praktisch geprüft werden.

Für Website und Wissensarchiv bleiben die vorhandenen Redaktions-, Cache-, Veröffentlichungs- und Sicherungsabläufe maßgeblich. Git ist auf das eigenständige Familienarchiv begrenzt.

Fazit

Die fachlich richtige Frage lautet nicht:

Git – ja oder nein?

Sondern:

Für welchen Bestand löst Git eine tatsächlich benötigte Aufgabe?

Für mein Familienarchiv dokumentiert Git frühere Fassungen und den Zeitpunkt einer Veränderung. Die fachlichen Gründe bleiben bei den Quellen, Personenakten und Chroniken. iCloud bleibt der Arbeits- und Synchronisationsort; das NAS bewahrt die zentrale, automatisierte Versionshistorie.

Git ersetzt weder Backup noch Prüfsummen oder verständliche Archivstrukturen. Es ergänzt sie an einer klar definierten Stelle.

Kein Git für alles. Aber Git dort, wo eine nachvollziehbare Entwicklungsgeschichte einen echten archivischen Mehrwert schafft.

Weiterführend:

• Warum ich Codex nutze – im Zusammenspiel mit ChatGPT und Google
• Codex-Arbeitscache und grünes Denken
• Paperless-ngx 3.0 sicher aktualisieren: ein Praxisbericht
• Backup und Langzeitbewahrung
• Governance für digitale Privatarchive
• Bit Rot, Prüfsummen und Datenintegrität