Nennen wir es mal beim Namen: Jeder schreibt mit Word (OpenOffice, Pages, was auch immer), und jeder weiß irgendwie auch: Große Dokumente mit Word zu schreiben, das ist nicht schön. In Word entstehen in der Wissenschaft Forschungsförderanträge und Qualifikationsarbeiten, und Stunden, Minuten, vielleicht auch einen Tag passiert es quasi immer: Textverarbeitung schmiert ab, kaputtes Dokument, was auch immer – und dann herrscht die nackte Existenzangst.
Ein bisschen was über Datensicherheit bei der Abschlussarbeit wollte ich schon länger schreiben, und daran soll hängen wie man Word am besten los wird.
Aber ok – eins nach dem anderen. Damit man erkennt, dass man besser erst Text schreibt und dann ein Dokument erzeugt, sollte man die Vorteile kennen. Die Nachteile liegen nämlich auf der Hand: Wer in Plaintext oder Markdown schreibt, hat vom Tag 0 bis zum absoluten Schluss nichts, was wie eine fertige Arbeit aussieht in der Hand. Und das ist vielen doch erstmal wichtig: Ein formatiertes Deckblatt, Seitenzahlen (ich bin schon bei Seite 3 von 120 usw.).
Reiner Text (mit oder ohne Formatierungssprachen wie Markdown oder LaTeX) hat riesige Vorteile: Er ist enorm schlank (speichert eben nur die tatsächlich getippten Zeichen), er ist enorm universell (auf jedem Betriebssystem seit “immer” gibt es einen Texteditor) und portierbar. Und er wird – wenn man es richtig angeht – immer korrekt dargestellt, es gibt keine Themen wie “altes Dateiformat” etc.
Gut, erstmal aber noch nicht predigen, sondern die erste Technik vorstellen: Eigentlich will man in Plaintext schreiben, damit man richtig versionieren kann. Im Grunde ist das die “Programmierfähigkeit”, die Geisteswissenschaftlern enorm gut zu Gesicht stünde, nämlich zu schreiben wie ein Programmierer. Und egal mit welchem Werkzeug – Programmierer schreiben in ein Versionskontrollsystem. (Jetzt wird’s etwas blumig, ihr könnt auch direkt zum Versionieren springen mit diesem Link)
Klingt nach Aufwand
Ja, ist es. Aber dem Zweck angemessen
Klingt fürchterlich technisch und undurchschaubar
Möglich. Versionskontrolle ist nicht ganz simpel, aber moderne Tools nehmen einem fast alle Arbeit ab. SourceTree z.B. ist kostenlos und kann quasi alles.
Reicht es denn nicht, Arbeitskopien von Zwischenständen zu behalten?
Klar würde das auch gehen. Aber sie liegen dann halt rum und schaffen Unordnung. Besser wäre doch, wenn man von jedem Dokument nur eine Instanz hat, und die auf einen beliebigen Stand zurücksetzen kann.
Ich mache immer eine Kopie auf meinen USB-Stick!
Ja, nee. Das macht so keinen Sinn. Technisch ist der USB-Stick eine der schlechtesten Lösungen.
- Da drin arbeitet Flash-Speicher, und sehr wahrscheinlich von der geringsten Güte und geht (relativ) schnell kaputt (Flash-Speicher nutzt sich v.a. beim Schreiben von Daten ab).
- Der Beziehungsstatus zwischen Rechner und Speicherstick: In Facebook-Sprache “es ist kompliziert”. Es gibt einen Unterschied zwischen der Dateiliste und den Dateien, die Euer Computer auf dem USB-Stick sieht und der tatsächlichen physikalischen Speicherung dieser Daten. Das wird für Euch unsichtbar “übersetzt”. Außer, ihr zieht den Stick einfach ab, während eine offensichtliche oder weniger offensichtliche Aktivität auf den Stick zugegriffen habt. Danach muss zwar nicht gleich alles im Eimer sein, aber kann schon. Und “kann” ist immer schlecht wenn man sicher sein will.
Und wie soll’s denn nun sein?
Es gibt drei Orte für ein Backup – der erste ist der Computer selbst, der zweite ein externes Medium an Eurem Standort, der dritte außerhalb Eurer Wohnung. Was sicher sein soll, braucht eine direkte Kopie, eine Kopie im Bereich Eures unmittelbaren Zugriffs, aber getrennt vom Computer und eine Kopie getrennt von Eurem Computer und Eurem unmittelbaren Zugriff.
Fälle eins und zwei könnt ihr sicherlich selbst ableiten. Der dritte Fall ist schwieriger: Dienste wie Dropbox oder OwnCloud bringen Eure Daten souverän außer Haus, aber sie synchronisieren auch Fehler “in die Cloud”. Ein FTP-Upload wäre hier sicherer, aber umständlicher. Eine Festplatte an Mama schicken ginge auch. Eine Festplatte an der Arbeit, eine zuhause – auch nicht schlecht.
Wie wäre es, einfach mal mit Git als Versionskontrolle und einem Remote-Repository als Backup zu arbeiten?
Wir machen hier einfach mal einen wilden Ritt durch das aktuell populärste Versionskontrollsystem – glaube ich zumindest 😉 – nämlich git.
Ein Versionskontrollsystem überwacht einen Ordner und seine Unterordner auf Eurem Computer auf Veränderungen. Genauer gesagt: Dateien, die ihr auf die Überwachungsliste gesetzt habt. Bei Textformaten kann die Versionskontrolle die Unterschiede besonders effektiv erfassen speichern und darstellen, bei Binärdateien (Bilder, Word-Dokumente) wird jeweils die veränderte Version komplett erkannt und gespeichert). Die Dateiliste, die überwacht wird, wird dabei in einer nicht sichtbaren Datei zusammengefasst, in der alle Versionierungsschritte gespeichert werden. Das nennt man Repository oder kurz Repo.
Immer, wenn ihr eine Änderung speichert, bemerkt die Versionskontrolle eine Änderung, macht aber nichts – außer, die Urpsrungsversion der Datei ebenfalls im Hintergrund zu behalten.
Dann kommt der Punkt, wo ihr zufrieden mit Euren Veränderungen seid und nicht nur speichert, sondern auch einen COMMIT macht. Das ist sozusagen Speichern mit Anlegen eines neuen Versionsschritts. Im Hintergrund existiert nun die Ausgangsfassung, die veränderte Fassung und eine Arbeitskopie ohne Veränderungen gegenüber der veränderten Fassung. Wenn ihr direkt in das Verzeichnis schaut, seht ihr aber nur eine Datei – die Arbeitskopie. Theoretisch könnt ihr nun aber diese Arbeitskopie auf die Ausgangsfassung oder die Fassung des ersten Commits setzen.
Allerdings findet das alles lokal auf Eurem Rechner statt. Wenn ihr den Arbeitsstand aber nicht nur lokal, sondern auch “in der Cloud” speichern wollt, um ein Backup zu haben oder gemeinsam mit anderen zu arbeiten, müsst ihr einen ORIGIN hinzufügen. Das ist ein weiteres Repositorium, das aber woanders liegt – lokal oder per Netzwerk erreichbar.
Ihr könnt nun einen PUSH machen, d.h. Euer lokales Repositorium in das Repo am Ort des Origin kopieren. Alle Eure Arbeitsschritte sind nun auch dort verfügbar.
Alle anderen Schritte tun erstmal nichts zur Sache, aber da kommt dann eine Menge Magie ins Spiel und ihr werdet es lieben lernen.
Das klingt jetzt alles fürchterlich kompliziert – vor allem für technische Neulinge?
Geht ganz einfach, weil Atlassian ein kostenloses und recht gutes Tool hat. Ihr macht Euch einfach einen Bitbucket-Account – das ist dann Euer Origin. Dann ladet Ihr Euch SourceTree, installiert es und verbindet es mit Eurem Bitbucket-Account. Und dann könnt Ihr im Repository-Browser “+ Neues Repository” drücken und ein “entferntes Repository erstellen”. Im Dialog werdet ihr gefragt, wie das Repo heißen soll, in welchem Ordner auf Eurem Rechner es liegen soll, und ob es privat (nur für Euch und Teammitglieder) oder public (für alle zugreifbar) sein soll.
Auf der linken Seite findet Ihr nun “Dateistatus” – “Arbeitskopie” und in der nächsten Spalte zwei Abschnitte “vorgemerkte Dateien” und “nicht vorgemerkte Dateien”. “Vorgemerkt” heißt überwacht. Also ein paar Dateien in den überwachten Ordner werfen und “vormerken”.
Alles vorgemerkt? Dann oben links den Button “Commit” drücken – Zwingend ist nun eine Commit-Message verlangt (normalerweise beschreibt man kurz, was man geändert hat und fügt ggf. auch eine ausführliche Beschreibung an). Es gibt ein Häkchen “Push changes immediately to origin/master” und einen Bestätigungsbutton “Commit”. Ohne Häkchen wird die erste Version nur lokal gespeichert, mit Häkchen auch direkt auf dem Server gespeichert.
Dieser Schritt ist wichtig: Vor der ersten Veränderung sollten die verwendeten Dateien alle erst einmal eingecheckt werden, denn sonst wird Eure erste Veränderung nicht versioniert. Das ist natürlich solange egal, solange Euer erster Veränderungsschritt nicht das Löschen einer Datei ist.
Solltet Ihr Euch darauf verlegen, erstmal nur zu “committen” (ohne Push), dann müsst ihr früher oder später einmal alle Veränderungen pushen.
Die typischen Regeln sind:
- ein Commit für jeden essentiellen Arbeitsschritt.
- push muss nur dann sein, wenn
- ein Team auf Deine Änderung wartet
- Du Deinen Arbeitstag oder einen wichtigen Arbeitsschritt beendest oder Du sicher sein willst, dass eine Kopie außerhalb Deines Rechners gespeichert wurde.
Tja, und damit wäre dann schon der Einstieg in git und ein Leben ohne USB-Stick gemacht.
Wer experimentieren will: Klont Euch https://dst14DH@bitbucket.org/dst14DH/gettingstartedwithgit.git, verändert die Datei oder fügt eine neue ein und schickt mir einen Pull Request – das ist die formale Anfrage, Eure Änderungen in mein Repo aufzunehmen. Viel Spaß beim Experimentieren und Nachlesen, wie das geht 😉 – kleiner Tipp per Screenshot:
Links
- Bitbucket – für Teams bis zu 5 Benutzer kostenlos
https://bitbucket.org/account/signup/ - Source Tree – kostenloser Git Client für Windows und Mac
https://www.sourcetreeapp.com/ - Scott Chacon, Ben Straub: Pro Git – das “Handbuch” für Git
https://git-scm.com/book/de/v1 (in Deutsch, 1. Auflage 2009)
https://git-scm.com/book/en/v2 (in Englisch, 2. Auflage 2014) - Für Mutige, die Kommandozeile lernen wollen: Try Git – die ersten Schritte in Git online üben:
https://try.github.io/levels/1/challenges/1