Versionsmanagement

• Warum?
• Wie?
• Praktische Anwendung

Ordner für Ursprungsdaten, Auswertungsskripte und Ergebnisse

Beispiel:

   Projekt/Daten/ALLBUS
   Projekt/Daten/SOEP
   Projekt/Skripte/Aufbereitung
   Projekt/Skripte/Funktionen
   Projekt/Bericht

Wissenschaftliches Schreiben ist oftmals ein Kooperationsprojekt

Hilfsmittel:

• MS Word oder OpenOffice mit Überarbeitungsfunktion
• Online-Editoren wie ShareLaTeX oder overleaf
• Versionsverwaltungen GitLab oder Github

Einfaches Verständnis:

• Eine Datei wird erzeugt: Version 1
• Eine Änderung wird daran vorgenommen: Version 2
• Version x ist also die x. Änderung der ursprünglichen Datei.

• Nicht so wichtig für kleinere (eigene) Dinge
  • mal einen Brief schreiben
  • mal schnell eine Auswertung machen
• Wichtig für Teamwork
  • was hat die Kollegin gemacht
  • woran wurde zuletzt gearbeitet
• Wichtig für große und größere Projekte
  • was war vor mehreren Wochen
  • was hat die Gruppe aus Bayern gemacht

Platon und Aristoteles schreiben zusammen an einem Aufsatz.

• Platon hat einen Teil fertig geschrieben. Den schickt er seinem Kollegen.
• Aristoteles war in der Zwischenzeit nicht untätig und hat ebenfalls etwas geschrieben.
• Aristoteles fügt die beiden Teile zusammen.
• Während er noch damit beschäftigt ist, gehen weitere Änderungen ein.
• Platon fügt immer mehr Dateien zusammen.

• Nach einiger Zeit muss sich Platon leider eingestehen, er weiß nicht mehr, wer welchen Teil des gemeinsamen Aufsatzes geschrieben hat.
• Noch schlimmer, die beiden haben eine Reihe von Auswertungen gemacht und er weiß nicht mehr wann die Ergebnisse zuletzt aktualisiert wurden.

Die einfachste Lösung

• Verschiedene Versionen mit unterschiedlichem Titel abspeichern. Dann kann anhand des Änderungsdatums der Datei gesehen werden, wann Änderungen vorgenommen worden sind.

  Aufsatz_01.tex

• Abgleich er der Inhalte der Dateien Wort für Wort, um herausfindenden, welche Änderungen durchgeführt wurden.

• Wird zudem noch den Autor der Version mit in den Titel dazu geschrieben, kann auch im Nachhinein noch festgestellt werden, wer die Änderungen durchgeführt hat.

  Aufsatz_02_Platon.tex

Im wesentlichen, genau das gerade beschriebene

• Es werden Änderungen an einer Datei nachverfolgt.
  • Wer hat die Datei bearbeitet?
  • Wann wurde die Datei bearbeitet?
  • Was wurde mit der Datei gemacht (gelöscht, erzeugt, verschoben oder bearbeitet)?

• Eine Versionsverwaltung erzeugt neben einer bearbeiteten Datei noch einige Dateien in denen weitere Informationen gespeichert werden. Dadurch existiert für den Anwender immer nur die jeweils aktuellste Version einer Datei.
• Funktioniert am besten mit Text-Dateien (Dateiendung txt, oder R-Skripten, Stata Do-Files, SPSS Syntaxdateien oder tex-Dateien).

• Binärdateien können ebenfalls in Versionsverwaltungen genutzt werden, allerdings ist der Abgleich unmöglich.
• Wie sich beispielsweise zwei Word-Dateien von einander unterscheiden findet man am leichtesten unter Word raus, genauso verhält es sich mit diversen anderen Dateiformaten.

• Aus zwei Versionen einer Datei erzeugt eine Versionsverwaltung eine neue Datei, die die Differenz beider Dateien enthält. Eine solche Datei nennt sich diff oder patch.
• Hat Platon im gemeinsamen Text eine Zeile hinzugefügt, entsteht ein diff aus den beiden Datei-Versionen.
• Aristoteles braucht nun lediglich die Datei mit den Unterschieden anzusehen und muss nicht erst die gesamte vorherige Datei durchsuchen.

• Eine Versionsverwaltung automatisiert den Prozess der Erzeugung von Differenzen und die beiden Griechen können sich auf das Philosophieren konzentrieren.
• Versionsverwaltungen funktionieren darüber hinaus dezentral, auf ihren Computern haben beide also nur eine Kopie des Verzeichnisses, welches auf einem Server liegen kann.
• Hat Platon eine Änderung auf den Server eingespielt, aktualisiert Aristoteles seine Kopie mit der Version auf dem Server.

• Open Source
  • CVS +
  • Subversion (SVN) +
  • Mercurial (hg) *
  • Git *
• Closed Source
  • Bitkeeper
  • Perforce

• R wird mit Subversion entwickelt
  • https://svn.r-project.org/R/
• RStudio wird mit Git entwickelt
  • https://github.com/rstudio/rstudio

Git herunterladen und installieren git-scm.com

• Ausführliche Git Dokumentation im Git Buch
• Kurzübersicht zur Versionsverwaltung mit RStudio

Git Repositories (Ordner unter Versionsverwaltung) können

• lokal angelegt werden (nur ein Verzeichnis auf einem PC/Server)
• oder über Internetplattformen wie Gitlab oder Github

Das Network Operations Centers (NOC) der Ruhr-Uni hat eine Gitlab-Installation

• Die Anmeldung erfolgt für Angehörige der RUB einfach mit LoginID und dem dazugehörigen Passwort: git.noc.ruhr-uni-bochum.de
• Zur Übung wird ein neues Projekt angelegt

• Über das Startmenü "Git Bash" oder "Git CMD" starten

• Zuerst sollte man seine Benutzerinformationen angeben

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

• Anschließend den jeweiligen Lieblings-Editor als Standard festlegen (Standard ist vi)

  git config --global core.editor notepad

• Ein Projekt kann in der Kommandozeile git init ., über die "Git Gui" (Startmenü) oder über RStudio angelegt werden (Neues Projekt - Version Control - Git)
• Die Funktionen in RStudio sind sehr komfortabel, sofern einmal eingerichtet, erlauben allerdings bei weitem nicht die Nutzung des gesamten Funktionsumfangs von Git
• Für bestimmte Funktionen muss (zumindest aktuell) noch immer auf die Konsole zurück gegriffen werden (bspw. git merge)

• Nachdem man Änderungen an einer Datei vorgenommen hat, kann man diese als neue Version sichern und mit einem Kommentar versehen
• Dies kann über den Git-Reiter in RStudio geschehen oder über die Git Shell (über den Explorer oder RStudio aufrufen)

Git Reiter in RStudio

• Zunächst wird ein Ordner oder eine Datei in einem Ordner zum commit vorgemerkt

  git add ordner/datei

• Dann wird ein commit Text ergänzt und der commit eingetragen

  git commit -m "Ich habe eine wichtige Änderung vorgenommen"

• Zunächst wird eine Datei zur Änderung vorgemerkt:

  git commit dateiname.R

• Es öffnet sich der Editor und man muss einen Kommentar eingeben. Man kann den Kommentar auch direkt angeben

  git commit dateiname.Rmd -m "Ich habe eine wichtige Änderung vorgenommen"

• Hat man Änderungen in mehreren Dateien vorgenommen, können diese auf einmal versioniert werden

  git commit -a

• Möchte man diese Änderungen an der Server übertragen, werden mit git push alle neuen Änderungen auf den Server übertragen
• Mit git pull holt man sich den neusten Stand vom Server
• In RStudio gibt es dafür auch Einträge in der Symbolleiste des Git-Reiters

• Es kann vorkommen, dass mehrere Personen gleichzeitig einen Textabschnitt bearbeiten
• Oftmals kann git diese Änderungen automatisch zusammenführen (git erzeugt einen automatischen merge)
• Wenn git nicht automatisch erkennen kann, wie der merge erfolgen soll entsteht ein ("merge conflict")
• Dieser muss manuell gelöst werden
• Das ist nicht schwer!

• Git fügt beide Varianten in den Text ein und markiert die Stelle

  <<<<<<< HEAD
  # Line 1 a
  # Line 2
  # Line 3 a
  =======
  # Line 1
  # Line 2 b
  # Line 3
  >>>>>>> b2

• Man löst den Konflikt, indem man die Textstelle bearbeit und die Marker löscht.

• Konflikte kann man über die Eingabeaufforderung lösen
• In RStudio kann diese mit More -> Shell aufgerufen werden
• Alternativ öffnet man die Datei mit dem Konflikt und passt die problematische Stelle per Hand an

• Man commited nun alle Änderungen - Ein Kommentar wird bereits vorgegeben

  git commit -a

Neben der Kommandozeile gibt es zahlreiche grafische Oberflächen für Git

• Übersicht auf der Git-Homepage
• Git für Windows bringt bereits eine einfache Anwendung mit: Git Gui

Neues Projekt auswählen

Leeres Projekt auswählen

Einen Namen wählen und ein Git-Projekt erstellen

Dateien im neuen Projekt

Eine neue Dateie erstellt

Git Reiter mit Dateien

Dateien Auswählen

Neues Projekt wählen

Gitlabs Anweisungen folgen

Nach dem initialen Push gibt es jetzt auch Push und Pull in RStudio

• Ein neuer Branch kann nur über die Kommandozeile gewählt werden und muss auch von dort initial übermittelt werden.
• Ein Git Projekt gleichzeitig auf mehreren Server liegen. RStudio übermittelt immer nur an origin

Entwicklung in git kann nicht nur in einem Entwicklungszweig erfolgen.

• Häufig ist es ratsam instabile Entwicklungsschritte nicht im Hauptzweig zu entwickeln

• Einen Nebenzweig kann man mit git branch erzeugen

  git branch -b testing

• Ein neuer Branch wird mit -b erzeugt

Anschließend kann über

git checkout master

und

git checkout testing

zwischen beiden Zweigen gewechselt werden.

• Alle verfügbaren Zweige können mit

  git branch

  angezeigt werden

• Dabei können Zweige auf dem Server und lokal unterschiedlich sein

• Zweige zusammen führen kann man mit dem Befehl merge

• Ist im Branch testing eine Änderung eingetragen wechselt man auf den master kombiniert beide Zweige

  git merge testing

• Hierbei können merge Konflikte auftreten

• Bestimmte Änderungen können nicht auf jedes Repo eingetragen werden
• Beispielsweise kann man nicht ohne weiteres Repos dritter commiten
• Will man eine Änderung eintragen kann man ein bestehendes Repo clonen git clone
• Die Änderungen dann auf github/gitlab hochladen und dort einen Pull Request öffnen
• Ein Pull Request stellt die Bitte zur Zusammenführen von zwei Zweigen dar

• Dateien/Verzeichnisse ausschließen .gitignore
• Einzelne Commits aus einzelnen Zweigen holen git cherry-pick
• Änderungen nachträglich sauber zusammenführen git rebase
• Git commits taggen git tag
• Commit widerrufen: git revert
• Zweig zurückspulen git checkout ...
• Fehler finden git bisect
• Unterprojekte git submodule