Arbeiten mit Dateien

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

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
mit Speicherdiensten in der Cloud

durch Dateinamen-Missbrauch:

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

oder durch Gedächtnisanstrengung

Ausgestorbene Alternative: Versionierende Dateisysteme

Dennis Richie und Ken Thompson an einer PDP-11 (Anfang der 1970er) einer der letzten VAX-Rechner (1992)

Das versionierende Dateisystem Files-11 (alias ODS) stand ab den späten 1960er Jahren auf DEC-Minicomputern der PDP-Baureihe (links) mit dem Betriebssystem RSX-11 und ab 1977 auf der VAX (rechts) mit VAX/VMS, später OpenVMS zur Verfügung.

erstelle datei.typ → danach existiert datei.typ;1
bearbeite datei.typ → danach existieren datei.typ;1 und datei.typ;2
bearbeite datei.typ (ändert datei.typ;2) → danach existieren datei.typ;1 datei.typ;2 datei.typ;3

Bildquellen

Quelle

http://en.wikipedia.org/wiki/Versioning_file_system

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

Versionierungssoftware der ersten Generation

Hauptmerkmal: lokal

1972: SCCS (Source Code Control System) auf kommerziellen Unix-Systemen, POSIX-Standard
1982: RCS (Revision Control System) auf freien Unix-Systemen, Teil des GNU-Projekts

Einschränkungen

nur einzelne Dateien
nur Textdateien, keine binären Dateien
Sperren (locking) statt automatischer Konfliktauflösung (merging)

Quellen

Versionierungssoftware der zweiten Generation

Hauptmerkmal: internetfähig und zentral (client-server)

1989: CVS (Concurrent Versions System) ist anfangs ein Aufsatz auf RCS und
- ermöglicht gemeinsames Arbeiten an Dateien und Arbeiten übers Internet
- kann mehrere Dateien gleichzeitig verwalten, aber nicht umbenennen
1994: MS Visual SourceSafe
1995: Perforce
2000: Subversion (SVN) versucht, CVS zu verbessern durch:
- versionierte Verzeichnisse
- atomische Commits
- effiziente Handhabung von Binärdateien
- Merges gehen in die Versionsgeschichte ein
2005: MS Team Foundation Server

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

Zeitstrahl: Versionierungssoftware

Bildquelle

http://codicesoftware.blogspot.com/2010/11/version-control-timeline.html

Popularität

Datenquelle

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

Popularität 2.0

GitHub: Projekt-Hosting mit Social Web

Bildquelle

http://www.wired.com/wiredenterprise/2012/02/github/all/1

Git ready!

Installation:
- Download für gängige Betriebssysteme von http://git-scm.com/
- Linux-Paketmanager

Konfiguration

git config --global user.name "Max Mustermann"
git config --global user.email "Max.Mustermann@uni-bielefeld.de"

Arbeiten mit Git

Ein Projekt mit Git versionieren:

Projekte werden in Verzeichnissen verwaltet

git init legt ein Repository im aktuellen Verzeichnis an

~$ mkdir projekt
~$ cd projekt/

~/projekt$ git init
Initialized empty Git repository in .git/
~/projekt$ ls -a
.  ..  .git

git status: zeigt den aktuellen Zustand des Repositorys an

 ~/projekt$ git status
 # On branch master
nothing to commit (working directory clean)

Arbeiten mit Git

Dateien versionieren

Git erkennt zwar standardmäßig alle Dateien im Projektverzeichnis, versioniert diese aber nicht automatisch

~/projekt$ touch datei.txt

~/projekt$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#        datei.txt
nothing added to commit but untracked files present (use "git add" to track)

Arbeiten mit Git

`git add`

Mit git add kann man Git anweisen, Dateien zu "tracken", d.h. auf Änderungen hin zu überwachen

~/projekt$ git add datei.txt

~/projekt$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   datei.txt
#

Arbeiten mit Git

`git commit`

Nach git add ist die Datei noch nicht im eigentlichen Repository, sondern in einem Zwischenbereich (Staging area).
Erst mit git commit wird sie endgültig gesichert:
```
~/projekt$ git commit
```
Es öffnet sich ein Texteditor mit der Aufforderung eine Commit-Message einzugeben. Alternativ kann man diese auch direkt mit angeben:
```
~/projekt$ git commit -m "Added file datei.txt"
```

Die drei Git-Arbeitsbereiche

Arbeitsverzeichnis: Enthält aktuelle Version des Projekts
Staging area: Zwischenbereich zwischen Arbeitsverzeichnis und Repository; enthält Änderungen für den nächsten Commit
Git-Repository: Datenbank, welche die Versionshistorie (Commits) enthält (.git-Verzeichnis)

Entsprechende Arbeitsschritte:

git add <datei>: Überführt Änderungen vom Arbeitsverzeichnis in die Staging area
git commit: Übernimmt alle Änderungen aus der Staging area ins Repository

Wozu die Staging area?

In der Staging area können logisch zusammengehörige Änderungen in mehreren Dateien zu sinnvollen Commits zusammengefasst werden.
Dies muss nicht während oder in der Reihenfolge der Bearbeitung geschehen, sondern ist auch im Nachhinein noch möglich.

Beispiel: Code und zugehörige Dokumentation in einem Commit

git add module.py
git add documentation.txt
git commit -m "Created module + documented it"

Mit git add -p können sogar Teile aus verschiedenen Dateien ausgewählt und hinzugefügt werden.
Möchte man einfach alle Änderungen im Arbeitsverzeichnis committen, kann die Staging area mit git commit -a übersprungen werden.

Versionshistorie anzeigen

mit git log kann man sich die Versionshistorie ansehen:

git log
commit 70164885d0ef60ed5201ca6881613d0cc706e4fc
Author: Max Mustermann <Max.Mustermann@uni-bielefeld.de>
Date:   Wed May 2 15:50:53 2012 +0200

    Changed page title

commit 23216a54cf49ef7f47cbeff8ad645545f2abc377
Author: Max Mustermann <Max.Mustermann@uni-bielefeld.de>
Date:   Wed May 2 15:48:46 2012 +0200

    Added another bullet point

Jeder Commit wird mit einer Hashsumme identifiziert
Um das Projekt auf den Stand eines bestimmten Commits zu bringen, verwendet man git checkout <hash>
Dabei muss man nicht den ganzen Hash angeben, sondern nur soviele Zeichen bis der Hash eindeutig referenziert werden kann.

Branches

Manchmal möchte man etwas ausprobieren, was aber möglicherweise erst einmal den erreichten Entwicklungsstand zerstört, z.B.:
- Neue Programmbibliothek
- Neues CSS-Design
- Neue Kapitelstruktur für die Abschlussarbeit
Mit git branch kann man mehrere Versionen desselben Projekts parallel verwalten
Einen neuen branch legt man mit git branch <name> an:
```
git branch test
```
Das Arbeitsverzeichis auf den Stand des neuen branch bringen:
```
git checkout test
```
Beides in einem Schritt:
```
git checkout -b test
```

Branches

Branches anzeigen:
```
git branch
* master
  test
```
Das Sternchen * markiert den aktuell ausgecheckten branch
Der Hauptbranch heißt master und ist standardmäßig angelegt und ausgecheckt
Branches löschen:
```
git branch -d test
```

Merging

Wenn man auf dem neuen branch fertig ist, kann man die Entwicklungen in den Hauptbranch mit git merge übernehmen
Dazu führt man folgenden Befehl im branch master aus:
```
git merge test
```
Wenn in beiden branches nur unterschiedliche Änderungen gemacht wurden, kann Git die Zusammenführung automatisch erledigen:
```
Updating 8cfeb67..57b272d
Fast-forward
 app.py |    1 +
 1 file changed, 1 insertion(+)
```

Merge-Konflikte

Wenn auf zwei zusammenzuführenden branches z.B. dieselbe Zeile geändert wurde, weiß Git nicht, welche Version die "richtige" ist:

git merge test
Auto-merging documentation.txt
CONFLICT (content): Merge conflict in documentation.txt
Automatic merge failed; fix conflicts and then commit the result.

Die Dateien, die Konflikte verursachen, werden angegeben und enthalten dann Informationen aus beiden branches, z.B.:
```
<<<<<< HEAD
Die erste Zeile auf master.
=======
Die erste Zeile auf test.
>>>>>>> test
```
Der Nutzer muss nun die Dateien in die finale Version bringen und den Commit durchführen.

Remote Repositories

Als dezentrales Versionskontrollsystem kann Git mit externen Repositories umgehen
Die externen Repositories können z.B. an folgenden Orten liegen:
- im Filesystem
- im lokalen Netzwerk
- im Internet
Beispielsweise kann eine Repository-Instanz auf dem Server in der Uni liegen und über SSH angebunden werden
Dazu muss auf dem Server ein Repository-Ordner liegen. In der Regel ist dies ein so genanntes "bare repository", d.h. nur die Git-Versionsdatenbank.
```
user@myserver:/opt/git$ mkdir myrepo.git
user@myserver:/opt/git$ cd myrepo.git
user@myserver:/opt/git/myrepo.git$ git init --bare
```

Remote Repositories II

Um lokal eine Verbindung zum Remote Repository auf dem Server herzustellen verwendet man git remote:
```
git remote add myserver ssh://user@myserver/opt/git/myrepo.git
```

Remote Repositories werden in sog. remote branches verwaltet

git remote -v
myserver ssh://user@myserver/opt/git/myrepo.git (fetch)
myserver ssh://user@myserver/opt/git/myrepo.git (push)

Clone

git clone holt ein Remote Repository mit der gesamten History und legt eine lokale Kopie an
```
git clone ssh://user@myserver/opt/git/myrepo.git
```

Geklonte Repositories haben automatisch einen remote branch origin

git remote -v
origin ssh://user@myserver/opt/git/myrepo.git (fetch)
origin ssh://user@myserver/opt/git/myrepo.git (push)

Push, Fetch und Pull

git push überführt lokale Commits in ein Remote Repository
Lokal angelegte branches müssen explizit zum Server gepusht werden. Dies ermöglicht "private branches", auf denen man lokal etwas ausprobieren kann, ohne dass eventuelle Mitarbeiter es automatisch mitbekommen.
```
git push origin master
git push origin test
```
git fetch holt neue Commits von einem Remote Repository in einen remote branch
```
git fetch origin master
```
git pull holt neue Commits von einem Remote Repository und versucht automatisch in den aktuellen branch zu mergen
```
git pull origin master
```

Nur am Rande …

git hook scripts: Skripte, die bei bestimmten Aktionen (commit, push, pull) automatisch ausgeführt werden
- Nützlich z.B. für automatisches Web-Deployment: Ein Skript, welches bei jedem empfangenen push die HTML- CSS- und Bild-Dateien automatisch an ihre richtige Stelle kopiert.
git rebase: Reihenfolge der Commits nachträglich ändern
Git Web Frontends

GitHub

GitHub (http://github.com) ist ein Hosting-Service für Remote Repositories
Die Vorteile von GitHub sind eine komfortable Web-Verwaltung der eigenen Repositories sowie "soziale" Features:
- Öffentliche Verknüpfung der eigenen Repositories mit persönlichem Account
- Kommentarfunktion unter Commits
Hosting bei GitHub ist für Open-Source-Projekte kostenlos
Ein Repository kann von GitHub einfach geklont werden:
```
git clone https://github.com/LibreCat/Catmandu.git
```
Für die Verwaltung eigener Repositories kann man seinen SSH Public Key zu GitHub hochladen und dann per git push und git fetch/pull mit GitHub interagieren.

Zusammenfassung

Git ist ein mächtiges und z.T. auch komplexes Werkzeug
Man muss nicht alle Funktionen verwenden um produktiv damit arbeiten zu können
Lokale Versionierung der eigenen Arbeit ist einfach
Vernetzung mit anderen + Kollaboration kann auch später begonnen werden

Literaturtipps

Bücher:

Git Community Book http://book.git-scm.com/
Pro Git http://progit.org/

Lösungen für Einzelprobleme

git ready http://gitready.com/

Vielen Dank!

Bildquelle

http://github.com

Über diese Präsentation

Diese Präsentation hält sich an W3C-Standards (XHTML 1.0), ist archivierbar und wurde ausschließlich 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 versionieren_mit_git.txt
```

Versionieren mit Git

Arbeiten mit Dateien

Wir alle versionieren

Ausgestorbene Alternative: Versionierende Dateisysteme

Was bietet Versionierungssoftware?

Versionierungssoftware der ersten Generation

Einschränkungen

Versionierungssoftware der zweiten Generation

Versionierungssoftware der dritten Generation

Zeitstrahl: Versionierungssoftware

Popularität

Popularität 2.0

Git ready!

Arbeiten mit Git

Ein Projekt mit Git versionieren:

Arbeiten mit Git

Dateien versionieren

Arbeiten mit Git

git add

Arbeiten mit Git

git commit

Die drei Git-Arbeitsbereiche

Entsprechende Arbeitsschritte:

Wozu die Staging area?

Versionshistorie anzeigen

Branches

Branches

Merging

Merge-Konflikte

Remote Repositories

Remote Repositories II

Clone

Push, Fetch und Pull

Nur am Rande …

GitHub

Zusammenfassung

Literaturtipps

Vielen Dank!

Über diese Präsentation

`git add`

`git commit`