User Tools

Site Tools


doku:wissenschaftliches_schreiben_mit_git_und_latex

This is an old revision of the document!


Wissenschaftliches Schreiben mit git und LaTeX

siehe auch: Versionsverwaltung mit git

Diese Anleitung ist noch unvollständig und wird weiter ausgebaut.

LaTeX ist als Textsatzprogramm zum Erstellen wissenschaftlicher Arbeiten, Artikel und Bücher im akademischen Umfeld weit verbreitet. Vorteile sind einfacher Mathematiksatz, Erweiterbarkeit und Anpassbarkeit durch Pakete und eigene Makros, sowie die unübertroffene Satzqualität. Außerdem erlaubt das Textformat Automatisierung mit einfachen Skripten.

In diesem Tutorial soll es um einen anderen Vorteil gehen, den LaTeX für das akademische Schreiben hat: Das Textformat erlaubt die Verwendung eines Versionskontrollsystems. Die Zielgruppe dieser Anleitung sind alle, die LaTeX schon verwenden (oder gerade erlernen) und keine Angst vor der Shell haben (und am besten ein Unix-System verwenden).

Eine Kurze Einführung in Verteilte Versions- & Variantenverwaltung und git

Die Idee von Versionskontrollsystem ist, dass man zu einem Dokument (oder einem Verzeichnisbaum) auch auf alle vorigen Versionen zugriff hat und Werkzeuge hat um Änderungen zu verwalten (z. B. abgleichen mit den Änderungen die jemand anderes an den Dateien vorgenommen hat, paralleles Bearbeiten verschiedener Versionen). Außerdem machen Versionskontrollsysteme es leicht die gesamten Daten auf mehrere Computer zu verteilen und synchron zu halten. Ein Verzeichnisbaum zusammen mit seiner Bearbeitungsgeschichte nennt man Repository (kurz Repo).

Die Variantenverwaltung ergänzt dieses Konzept der linear aufeinander folgenden Versionen durch Branches (auf deutsch etwa: Äste oder Zweige). Dies wird aber erst später im Abschnitt über Branches behandelt.

git gehört zu der (modernen) Klasse der Verteilten Versionskontrollsysteme, das heißt, dass jede Kopie der Daten technisch gleichberechtigt ist (es ist lediglich eine Frage der Konvention, welche Version die “offizielle” ist). Es können also mehrere Nutzer gleichzeitig an den Dokumenten arbeiten, und wenn sie das abgeschlossen haben, können sie git verwenden um die Versionen zu einer zusammenzuführen (mergen) die die Änderungen beider enthält. Falls beide die gleiche Stelle bearbeitet haben sollten, dann gibt es einen Konflikt, der manuell aufgelöst werden muss.

Im nächsten Abschnitt wird allerdings zunächst gezeigt, warum git auch für einen einzeln Arbeitenden von Vorteil ist.

Weiterführende Links:

Beispiel: git für Einen

Um dem Tutorial im weiteren zu folgen müssen die Programme git und (optional aber empfohlen) gitk installiert werden.

Szenario

Bob schreibt eine Hausarbeit. Da er in der Vergangenheit schon oft durch Missgeschicke Änderungen verloren hat oder nach fehlgeschlagenen Verbesserungen an einem Absatz diese nicht wieder loswerden konnte ohne die Verbesserungen an einem anderen Absatz mühsam manuell in seine Sicherheitskopie zu übertragen, möchte er nun git für die Versionsverwaltung einsetzen.

Erste Schritte

Zunächst legt Bob einen Ordner an und intialisiert diesen als git Repository:

$ mkdir Hausarbeit
$ cd Hausarbeit
$ git init

Als nächstes legt er eine Datei .gitingore mit folgendem Inhalt an:

# ignore emacs backup files
*~
# ignore TeX auxiliary files
*.aux
*.toc
# ignore compiled pdf files
*.pdf

(TODO: Ist es sinnvoll, das hier jetzt schon zu sagen, ohne vorher git status erwähnt zu haben? Macht das die Sache nicht unnötig kompliziert?)

Damit wird festgelegt dass Dateien die den aufgeführten globs entsprechen von bestimmten git Kommandos ignoriert werden. Außerdem legt er die Datei arbeit.tex an und fügt die Präambel und eine leere document-Umgebung ein. Dann tippt er:

$ git add .gitingore arbeit.tex

Damit fügt er die Änderungen an den beiden Dateien zu dem Index hinzu.

$ git commit -m 'erster Commit'

Damit ist der jetzige Zustand des Index im git Repository verzeichnet und kann jederzeit wieder hergestellt werden.

Anlegen einer Sicherheitskopie

Da Bob auch eine Sicherheitskopie seines Arbeitsfortschritts haben will, steckt er seinen USB-Stick an und wechselt in ein Verzeichnis auf dem USB-Stick, dort tippt er:

$ git clone /pfad/zu/Hausarbeit

Damit ist eine vollständige Kopie des aktuellen Standes auf dem Stick (er hat das Repository geklont). Wenn er später wieder den Stand aktualisieren will, wechselt er in das Verzeichnis Hausarbeit auf dem USB-Stick und tippt:

$ git pull

TODO: Vielleicht doch lieber ein bare-Repo klonen und dahin pushen, sind Auto-Mount-Points stabil (dann ist das kein Problem)? Auch noch andere Varianten erläutern (ein git server, per ssh auf eine andere Maschine).

Bearbeiten der Dateien und Übernehmen der Änderungen

Bob schreibt nun eine Einleitung für seine Arbeit. Nachdem dies geschehen ist, tippt er:

$ git add arbeit.tex
$ git commit -m "Einleitung geschrieben"

Alternativ könnte er auch nur git commit (ohne die -m -Option) eingeben und seine Commit Message, also eine kurz Beschreibung seiner Änderungen, in einem Texteditor eingeben, der dann automatisch geöffnet würde (in der Regel vi, das ist in der Umgebungsvariable $EDITOR festgelegt). Dort tippt Bob nun eine Commit Message, die eine Zusammenfassung seiner Änderungen enthält:

Einleitung geschrieben

Sobald er diese speichert und den Editor verlässt (im vi: Esc-Taste und dann :wq eintippen) ist die aktuelle Version der Arbeit gesichtert.

Um von den Änderungen auch eine Sicherheitskopie zu haben muss er nur in das Verzeichnis auf dem USB-Stick wechseln und

 $ git pull

ausführen. Um eine Übersicht über die Änderungen und die Dateien im Verzeichnis zu erhalten kann Bob jederzeit:

 $ git log

und

 $ git status

verwenden. (TODO: Erklären was git einem damit sagt).

Branches, Merges und ''git revert''

TODO

Kollaboration mit git

TODO

Automatisch erstellter Inhalt und Makefiles

TODO:

  • Mit Skripten automatisch Daten auswerten und daraus TeX-Source erzeugen
  • Makefiles verwenden um den build-Prozess zu automatisieren
  • bibtex/biber, makeglossaries

Siehe auch

doku/wissenschaftliches_schreiben_mit_git_und_latex.1488788595.txt.gz · Last modified: 2017/03/06 09:23 by norman