Backups für Autorinnen und Autoren
Überblick
Wer schreibt, sollte sich um eine ordentliche Backup-Lösung kümmern, damit die viele Arbeit, die in die Texte geflossen ist, nicht durch einen Hardware-Schaden oder eine Dummheit (z. B. ein versehentliches Löschen) zunichte gemacht wird. Dafür kann man natürlich immer wieder manuell Backups erzeugen, also die Dateien auf ein anderes Medium (z. B. einen USB-Stick) kopieren. Allerdings sind viele Lösungen nicht ideal und zeigen ihre Schwächen erst bei näherer Betrachtung.
Git ist ein Versionskontrollsystem das von Linus Torvalds entwickelt wurde, um die Quellcodes des bis heute von ihm verwalteten und nach ihm benannten Linux-Kernels zu verwalten. Git ist extrem mächtig und umfangreich, bietet Möglichkeiten, die weit über das hinausgehen, was man beim Schreiben von Geschichten braucht. Man kann sich bei der Nutzung aber leicht auf die benötigten Features beschränken. Ich werde auch die meisten gar nicht vorstellen (Dezentralität, Diffs, Multi-file-handling, Branching, Multi-User usw.).
GitHub ist eine Online-Lösung, die auf Git basiert und die Infrastruktur bereitstellt, Git komfortabel in der Cloud zu nutzen.
Ich werde im Folgenden erläutern, inwieweit GitHub als reine Backup-Lösung helfen kann.
Anforderungen an eine Backup-Lösung
Automatisierung
Manuelle Backup-Lösungen wie Kopien auf einem USB-Stick haben den Nachteil, dass die sich ständig wiederholenden notwendigen Schritte umständlich sind und dadurch aus Nachlässigkeit versäumt und/oder falsch gemacht werden können. Im Ergebnis ist die Chance hoch, dass das Backup nicht sauber und oft genug gemacht wird.
Mit einer Automatisierung kann diese menschliche Fehlerquelle vermieden werden. Damit wird dafür gesorgt, dass die Schritte unkompliziert sind, leicht auszuführen, wenig Zeit in Anspruch nehmen und immer korrekt erfolgen.
GitHub: Man kann jederzeit (z. B. am Ende einer Session) den aktuellen Bearbeitungsstand im Git-Repository einpflegen (commit). Dadurch wird er auch in Zukunft immer abrufbar bleiben. Der Schritt besteht lediglich darin, einige Buttons zu klicken.
Versionierung
Bei vielen Backup-Lösungen wird nur eine Version im Backup gespeichert oder es bleiben willkürlich ausgewählte Versionen erhalten. Dadurch besteht die Gefahr, dass ein Bearbeitungsschritt eine ungewollte und unbemerkte katastrophale Änderung (z. B. ein Leeren einer Datei, Löschen eines Kapitels o. Ä.) verursacht, die anschließend ebenfalls im Backup landet. Wenn dann nicht sichergestellt ist, dass auch ältere Versionen zugreifbar bleiben, kann u. U. auch das Backup den Fehler nicht wieder beheben.
Das Aufheben vieler Versionen in verschiedenen Dateien führt schnell zu einem unüberschaubaren Wust an Dateien mit Namen, die ihre Version widerspiegeln sollen. (Text_V1.doc, Text_V2.doc usw.)
GitHub: Man kann jeden vorher im Git-Repository abgelegten Versionsstand jederzeit wiederherstellen. Es ist immer nur eine Version der Dateien sichtbar, die Dateinamen spiegeln nicht den Versionsstand wider.
Geschwindigkeit
Das Erzeugen eines Backups kann je nach Strategie und Datenmenge durchaus erhebliche Mengen an Zeit verschlingen. Wenn der Benutzer aus der Erfahrung schon weiß, dass es lange dauern wird, ist die Gefahr höher, dass er das Backup verschiebt. Eine schnell arbeitende Lösung ist daher ein Vorteil.
GitHub: Git ist dafür bekannt, sehr schnell zu sein. Ein Grund liegt in der Tatsache, dass bei Git nur Deltas in das Repository übertragen werden. Da Git erkennt, welche Dateien sich geändert haben und (je nach Dateityp) auch erkennt, welche Teile der Dateien sich geändert haben, sind diese Änderungen oft sehr klein und können in sehr kurzer Zeit verarbeitet werden. Zudem ist diese Lösung zweistufig: Man hat ein lokales Repository, in das man seine Änderungen jederzeit einpflegen kann (alle paar Minuten oder Stunden), und die etwas zeitaufwändigere Kopie in die Cloud kann seltener erfolgen (am Ende einer Session).
Offsite-Backup
Wenn Backups nur lokal angelegt und gelagert werden (z. B. auf einem USB-Stick), dann besteht die Gefahr, die Originale zusammen mit den Backups zu verlieren, wenn ein Unglück den Standort zerstören sollte (Hausbrand, Hochwasser, Einbruch usw.). Ein Totalverlust droht.
Um das zu vermeiden, sollten Backups immer off-site, d. h. an einem anderen Standort gelagert werden. Bei der Verwendung physischer Medien bedeutet dies, diese regelmäßig zu transportieren, wobei sie ein erhöhtes Risiko haben, verloren zu gehen oder beschädigt zu werden.
GitHub: GitHub ist eine Lösung in der Cloud. Das Risiko eines Verlust der Daten aufgrund von Hardware-Defekten ist dort deutlich geringer, da der Anbieter entsprechende Vorkehrungen trifft (Redundanzen usw.). Da in GitHub lediglich eine Kopie des lokalen Git-Repositories abgelegt wird, ist es auch nicht notwendig, ständig online zu sein. Auch offline, also ohne Internetverbindung (z. B. im Flugzeug) kann man also Versionen im Repository ablegen und dann später nach GitHub übertragen.
Kosten
GitHub: GitHub ist kostenlos für kleine Anwendungen bis zu 500 MB (Stand 2024-02-11). Zum Verwalten von Texten ist diese Grenze vermutlich kein Problem. Für größere Anwendungen gibt es kostenpflichtige Modelle. Die benötigte Software (Git) ist Open Source und frei verfügbar; der unter Windows typische Client mit direkter GitHub-Anbindung (»GitHub Desktop«) ist ebenfalls kostenlos.
GitHub unter Windows in der Praxis
Installation
Um GitHub unter Windows zu verwenden, sind vier Schritte notwendig.
- Installation der GitHub-Software
- Anlegen eines GitHub-Kontos
- Anlegen eines lokalen Repositorys
- Einpflegen von Dateien ins Repository
1. Installation der GitHub-Software
Die Software GitHub Desktop findet sich unter desktop.github.com zum Herunterladen und Installieren. Bei der Installation wird man gleich gefragt, ob man auch ein Konto auf GitHub anlegen möchte.
2. Anlegen eines GitHub-Kontos
Mit Create free account kann man bei der Installation der Software gleich ein kostenloses Konto auf GitHub anlegen. Der Vorgang umfasst ein Einloggen in dieses Konto, wobei man gefragt wird, ob man die Software GitHub Desktop für Zugriffe autorisieren möchte; dies sollte man bestätigen, damit der Zugang im weiteren Verlauf unkompliziert ohne ständige Passwortabfragen erfolgen kann.
Natürlich ist auch die Nutzung eines bestehenden GitHub-Kontos möglich. Im Fall des Wiederherstellens eines Backups auf einem anderen Rechner wäre dieser Weg natürlich der richtige. (Zum Wiederherstellen siehe unten mehr.)
3. Anlegen eines lokalen Repositorys
Ein Repository hält alle Daten zu einem bestimmten Projekt. Ein zu schreibender Roman könnte z. B. so ein Projekt sein. Schreibt man mehrere Romane, legt man mehrere Repositorys an. Ein Projekt kann aus mehreren Dateien bestehen, die auch in Verzeichnissen strukturiert werden können.
Zu Beginn der Arbeit mit GitHub muss man daher ein Repository anlegen. Das erfolgt in der Software GitHub Desktop (Create a New Repository on your hard drive). Beim Anlegen des Repositorys muss man einige Dinge wählen:
-
Repositoryname
Hier eignet sich der Arbeitstitel des Romans oder ein beliebiger anderer Bezeichner.
Dieser Name wird als Verzeichnis angelegt, er sollte also entsprechend frei von kritischen Sonderzeichen sein. - Beschreibung
Eine längere Beschreibung (nicht notwendig). -
Lokaler Pfad
Hier gibt man ein Verzeichnis auf der lokalen Festplatte für das lokale Repository an. In dem gewählten Verzeichnis wird ein neues Verzeichnis mit dem Repositorynamen angelegt; das ist dann das lokale Repository.
Wenn man ein vorhandenes Projekt hat (z. B. C:\User\User\Desktop\Haus_des_Drachen) und dieses in ein Repository wandeln möchte, dann gibt man als Pfad das Verzeichnis oberhalb des Projektes an (C:\User\User\Desktop\) und als Repositorynamen den Verzeichnisnamen (Haus_des_Drachen). Alle vorhandenen Dateien des Projekts werden dann in die Initialversion des Repositorys übernommen. Die Dateien werden dabei auch nicht verändert; sie sind anschließend genau wie vorher in diesem bereits vorhandenen Verzeichnis zu finden.
4. Einpflegen von Dateien ins Repository
Dateien pflegt man in das vorhandene Repository ein, indem man sie dort anlegt bzw. sie dorthin verschiebt oder kopiert. Sie gelten dann zunächst als neue Objekte. Um sie im Repository einzupflegen (commit), öffnet man die Software GitHub Desktop. Dort werden alle neuen oder geänderten Dateien im Reiter Changes angezeigt. Mit dem Button Commit to main werden die Dateien ins Repository eingepflegt. Um den Button nutzen zu können, muss eine Notiz bei Summary eingetragen werden (diese kann aber auch nur ein Zeichen sein).
Die Software zeigt nach dem Einpflegen aller Änderungen an, dass keine lokalen Änderungen vorliegen (No local changes) und schlägt vor, das Repository nach GitHub zu kopieren. Dieser Vorgang nennt sich im Git-Jargon publish. Gemeint ist damit aber keine allgemeine Veröffentlichung, sondern das Publizieren für alle Projektmitarbeiter (die wir in unserem einfachen Beispiel nicht haben). Es wird mit diesem Button also nur alles nach GitHub in die Cloud kopiert.
Auf dem nächsten Dialog wird man nach dem Repositorynamen gefragt, unter dem man es publizieren möchte (da Repositorys lokal und auf GitHub unterschiedlich heißen können). Wir belassen es beim vorgeschlagenen lokalen Namen. Außerdem beachten wir, dass der Haken bei Keep this code private gesetzt ist. (GitHub dient vor allem der Kooperation in Open-Source-Projekten, bei denen man diesen Haken nicht setzen würde, damit die Welt den Inhalt des Repositorys sehen kann.)
Tägliche Nutzung
Bei der täglichen Nutzung, das heißt beim Schreiben, legt man neue Dateien in dem Repository an bzw. ändert bestehende – also man arbeitet ganz normal wie auch ohne Git und GitHub.
Am Ende jeder wesentlichen Session ruft man kurz die Software GitHub Desktop auf und sieht die erfolgten Änderungen gegenüber dem letzten Stand (im Reiter Changes). Die gewollten Änderungen kann man mit dem Button Commit to main einpflegen, die ungewollten kann man mit einem Rechtsklick→Discard changes… auf dem Eintrag rückgängig machen.
Anschließend kann man mit dem Button Push origin die gerade erfolgten Änderungen am lokalen Repository nach GitHub kopieren.
Wiederherstellung
Bei der Wiederherstellung eines Backups, also dem Restaurieren eines alten Zustandes unterscheiden wir zwischen zwei Fällen:
- Komplettverlust durch ein Unglück
- Versehentliche Änderung
1. Komplettverlust durch ein Unglück
Nach einem Unglück setzt man seinen neuen Computer genauso auf, wie oben beschrieben, allerdings mit zwei Änderungen:
- Man legt kein neues Konto bei GitHub an, sondern nutzt das schon vorhandene.
- Man legt kein neues lokales Repository an, sondern wählt in der Software GitHub Desktop im File-Menü den Punkt Clone repository… und wählt dann aus den angezeigten GitHub-Repositorys eins aus. Eventuell muss man den Local path noch anpassen, wenn dort schon etwas liegt (nach einem Neuaufsetzen des Computers sollte das aber nicht der Fall sein).
2. Versehentliche Änderung
Bei einer versehentlichen Änderung (z. B. dem versehentlichen Löschen eines Kapitels aus einem längeren Text) können wir in der Software GitHub Desktop den Reiter History anwählen. Wir sehen dann eine Liste des Stände (Commits), die in diesem Repository bekannt sind. Mit einem Rechtsklick auf dem Stand, den wir einsehen wollen, können wir Checkout commit wählen.
⚠️ Das funktioniert nur, wenn wir keine aktuellen Änderungen an den Dateien im Repository vorgenommen haben, die noch nicht eingepflegt sind. Haben wir also solche Änderungen, dann pflegen wir sie zunächst im Reiter Changes ein (Commit to main) oder machen sie rückgängig (Rechtsklick→Discard changes… auf der geänderten Datei).
Nach einem Warnungsdialog, dass wir auf dem Weg zu einem detached state sind, holen wir den gewünschten Zustand aus dem Repository.
Wir haben jetzt im Verzeichnis des Repositorys den Zustand unmittelbar nach dem damaligen Commit. Das umfasst alle (!) Dateien und Verzeichnisse in diesem Repository. Da dieser Zustand aber detached ist, ist er nicht dafür geeignet, geändert zu werden – es ist nur eine Sicht auf den alten Stand und sollte als read-only betrachtet werden.
⚠️ Technisch wird das Ändern dieser Dateien aber nicht verhindert (was schade ist), es ist nur nicht sinnvoll. Eventuelle Änderungen kann man nicht einpflegen, da sie nicht auf dem letzten Stand des Repositorys basieren. Diesen detached state sollte man nur nutzen, um die Dateien darin zu betrachten und ggf. ihre Inhalte an andere Orte zu kopieren. Ich rate daher dazu, ihn möglichst bald wieder durch einen attached state (das Normale) zu ersetzen.
Um nach dem Betrachten und Ausschlachten des alten Standes das Repository wieder auf den aktuellen Stand zurückzuführen, wählt man im zweiten Reiter (in dem Detached HEAD steht) den Eintrag main unter Default branch. Die Dateien, die man aus dem detached state herauskopiert hat, kann man jetzt hineinkopieren und so einen neuen Stand erzeugen, der dem gewünschten alten Stand entspricht. Diese Änderung (die faktisch einen Rückschritt zu einer früheren Version darstellt) kann man dann wieder einpflegen.
Keine Kommentare:
Kommentar veröffentlichen
Fragen zum Thema? Ist ein Fehler auf dieser Seite? Bitte melden! Sonstige Hinweise? Kritik? Lob?
Jeder Kommentar ist willkommen!