Table of Contents

1. GitLab für kollaborative Forschung und Entwicklung
2. Arbeiten mit Dateien
3. Gute und schlechte Dateiformate
4. Wir alle versionieren
5. Was bietet Versionierungssoftware?
6. Versionierungssoftware der dritten Generation
7. Popularität
8. Git vs. GitLab
9. GitLab-Strukturen
10. GitLab: Features
11. Use Case: GitLab für das Forschungsdatenmanagement
12. Wege ins Git-Repository
13. GitLab als eine Speicherlösung für PUB?
14. Zusammenfassung
15. Vielen Dank!
16. Über diese Präsentation

GitLab für kollaborative Forschung und Entwicklung

Christian Pietsch, Mathias Lösch
Universitätbibliothek Bielefeld, Kolloquium Wissensinfrastruktur, 26. April 2013

Arbeiten mit Dateien

Computerbenutzung basiert auf Dateien
Arbeiten mit Dateien ohne Versionierung ist wie Luftakrobatik ohne Sicherungsnetz

Gute und schlechte Dateiformate

Binärformat MS Word 97 vs. textbasiertes Format HTML

Textbasierte Formate sind besser als Binärformate, denn sie sind:

interpretierbar auch ohne Spezialsoftware
potentiell selbstdokumentierend
portierbar zwischen Programmen, Computern, Computerarchitekturen und Betriebssystemen
wiederverwendbar auch nach Jahren
und daher archivfest
versionierbar

Bildquelle

Stefan Münz, SELFHTML (Kopie auf http://www2.biochemtech.uni-halle.de/lernwww/tbdd.htm)

Wir alle versionieren

mit der Rückgängig-Funktion (Undo) z.B. in Office-Programmen
mit Änderungen verfolgen in Textverarbeitungen
beim Speichern in den meisten Wikis
durch Backups bzw. USB-Stick-Jonglage
mit Speicherdiensten in der Cloud

durch Dateinamen-Missbrauch:

Lebenslauf-alt.doc
Lebenslauf-ganz-alt.doc
Lebenslauf.doc.backup-summi
LebenslaufOkt2006.doc
Lebenslauf2006-10.doc
Lebenslauf200610.doc
Lebenslauf10-2006.doc
Lebenslauf10-2006.doc~

oder durch Gedächtnisanstrengung

Was bietet Versionierungssoftware?

Sichern und wiederherstellen: Beliebig viele Sicherungskopien, genau datiert.
Synchronisierung und gemeinsamer Zugriff: Abgleich beliebiger Änderungen mit anderen.
Kurzfristiges Rückgängigmachen: Etwas kaputt gespielt? Schnell zurück zur letzten guten Version!
Langfristiges Rückgängigmachen: Manche Fehler entdeckt man erste Jahre später.
Änderungen dokumentieren: Beim Einchecken sollte immer ein Kommentar eingegeben werden.
Wer hat welche Zeilen in einer Datei geändert? Auch das wird aufgezeichnet.
Sandboxing: Es ist möglich, Änderungen vor dem Einchecken zu testen.
Entwicklungszweige: Entwicklungen können parallel verlaufen (branch) und bei Bedarf verschmolzen werden (merge).

Quellen

http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://de.wikipedia.org/wiki/Versionsverwaltung

Versionierungssoftware der dritten Generation

Hauptmerkmal: dezentral/verteilt (peer to peer)

199x: Sun WorkShop TeamWare
2000: BitKeeper
2001: GNU arch
2002: Darcs
2003: Monotone
2005: Git
2005: Mercurial (hg)
2005: Bazaar (bzr)

Merkmale:

jede Arbeitskopie enthält auch ein vollständiges Repository
kann auch offline arbeiten, daher sehr schnell
Synchronisierungsoperationen wie push und pull erlauben Abgleich mit entfernten Repositorien
branch und merge sind einfach und effizient
Abspaltungen (forks) sind unproblematisch und sogar erwünscht
technisch sind alle Repositorien gleich; ob eines als offiziell gilt, kann verabredet werden

Popularität

Datenquelle

http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend

Git vs. GitLab

git: kommandozeilenbasierte Versionierungssoftware
GitLab: Webbasiertes Management für Git Repositories
http://gitlab.org/
freie, quelloffene Software unter der MIT-Lizenz
ähnliche Funktionalität wie GitHub, kann aber auf eigenem Server installiert werden

GitLab-Strukturen

Projekte (= git repositories): Enthalten zusammengehörige Dateien
Gruppen: Enthalten zusammengehörige Projekte
Teams: Enthalten zusammengehörige Personen

GitLab: Features

Gemeinsames Arbeiten an Dateien
Nutzer können einfach zu einem Projekt eingeladen werden
Visualisierung der Versionsgeschichte
- Änderungen werden den Autoren zugeordnet dargestellt
- Änderungen können kommentiert werden

Issue tracking

Demo: https://gitlab.ub.uni-bielefeld.de/

Use Case: GitLab für das Forschungsdatenmanagement

Vorteile:

Kollaboratives Arbeiten an den Daten
Versionierte Änderungen der Daten
Verteiltes Backup: Daten immer lokal und in GitLab vorhanden
Eindeutig referenzierbare Versionen eines Datensatzes
Kryptographisch garantierte Datenintegrität
Markierung von speziellen Versionen mit git tags

Nachteile:

Einarbeitung in Git nötig (evtl. Abstraktion?)
Nur für textbasierte Formate geeignet

Demo: https://gitlab.ub.uni-bielefeld.de/mloesch/baseresearch

Wege ins Git-Repository

Git-Werkzeuge für verschiedene Zielgruppen:

für ProgrammiererInnen: git auf der Kommandozeile, Git-Integration in Entwicklungswerkzeuge (IDEs und Texteditoren) wie Eclipse, Emacs
für Technikaffine: graphische Benutzeroberflächen (GUIs) für git: SmartGit, TortoiseGit mit Integration in den Windows Explorer
für alle: SparkleShare (wie Dropbox oder ownCloud; mit Software für Windows, Mac OS, Linux, Android, iOS)
für Wissenschaftler: via PUB?

Demo: https://gitlab.ub.uni-bielefeld.de/cpietsch/sparkleshare-data/

GitLab als eine Speicherlösung für PUB?

Mögliche Szenarien für Wissenschafter:

Gelegenheitsdatenproduzent: lädt ZIP-Datei in PUB hoch. PUB legt gleichnamiges Projekt auf GitLab an, speichert die Daten dort.
empirische Forscherin: nutzt SparkleShare, um immer den aktuellen Stand ihrer Daten mit GitLab synchron zu halten (und um ein Backup der Daten vom Laptop zu haben). Wenn sie ihre Daten zitieren will, fordert sie in PUB eine DOI an. PUB markiert den aktuellen Stand der Daten dabei mit der DOI als git-tag.
Forschungsprojekt: kann zusätzlich die GitLab-Funktionen wie Änderungsanzeige, Wiki, Issue-Tracker und Wall auf GitLab nutzen. Sonst wie bei der einzelnen Forscherin oben.

Die in GitLab mit Zeitstempeln versehene Änderungsgeschichte der Forschungsdaten kann bei Plagiats- oder Fälschungsverdacht als Nachweis herangezogen werden. Bsp.: Flämische Universitäten müssen seit kurzem einen Datenhinterlegungsdienst bereitstellen, um als förderwürdig zu gelten.

Zusammenfassung

Die UB Bielefeld kann externe Projektpartner zur gemeinsamen Arbeit an Software und Dokumenten auf einen eigenen GitHub-ähnlichen Server einladen.
Alle Forschenden müssen (früher oder später) ihre Rohdaten bei einem institutionellen Dienst hinterlegen. Das hat viele Vorteile für sie.
Viele Wege führen ins Git-Repository; manche sind so einfach wie Dropbox.

Vielen Dank!

Bildquelle

http://gitlab.org/

Über diese Präsentation

Diese Präsentation hält sich an W3C-Standards (XHTML 1.0), ist archivierbar und wurde mit freier Software erzeugt; insbesondere:
- Slidy: http://www.w3.org/Talks/Tools/Slidy2/
- AsciiDoc mit Slidy-Ausgabe: http://www.methods.co.nz/asciidoc/
Von AsciiDoc-Text in eine HTML-Datei mit eingebetteten Bildern, CSS und Javascript konvertiert mit folgendem Aufruf:
```
asciidoc --attribute=data-uri --backend=slidy gitlab.txt
```

slide 1/16

Space or Right Arrow to move to next slide, click help below for more details