Versionsverwaltung mit Git

1. Vorbereitung

Stelle zuerst sicher, dass du keinen Ordner geöffnet hast. Um sicherzugehen, drücke einfach den Shortcut für »Ordner schließen«: StrgK und dann F. Dein Workspace sollte jetzt ungefähr so aussehen:

Schließe die linke Seitenleiste mit StrgB, um mehr Platz zu haben, und öffne das Terminal mit StrgJ:

Mit dem Symbol rechts oben im Terminal kannst du es maximieren. Die linke Seitenleiste blendest du jederzeit mit StrgB ein und aus.

Im Handbuch nachschlagen

Erstelle als erstes ein Verzeichnis für dieses Tutorial, indem du im Terminal folgenden Befehl eingibst:

mkdir git-tutorial

Mit ls -l kannst du anschließend überprüfen, ob das Verzeichnis erstellt wurde (das d am Anfang der Zeile zeigt an, dass es sich um ein Verzeichnis handelt):

Wechsle anschließend in das neu erstellte Verzeichnis und lege ein Verzeichnis namens alice für eine fiktive Person Alice an:

cd git-tutorial
mkdir alice
cd alice

2. Alleine arbeiten

Ein Repository anlegen

Initialisiere jetzt ein neues Git-Repository mit dem Befehl git init:

Mit dem Befehl ls -la kannst du sehen, dass ein verstecktes Verzeichnis namens .git erstellt wurde:

Das .git-Verzeichnis enthält alle Informationen, die Git benötigt, um die Versionsgeschichte deines Projekts zu verwalten. Darin befindet sich später die gesamte Historie deiner Änderungen.

Die erste Datei

Erstelle jetzt eine Datei namens hello.txt mit dem Befehl echo:

echo "Hello, world!" > hello.txt

Überzeuge dich mit dem Befehl cat hello.txt, dass die Datei den erwarteten Inhalt hat:

Verwende nun den Befehl git status, um den aktuellen Status des Repositories zu überprüfen:

Die Staging Area

Die Ausgabe von git status zeigt, dass die Datei hello.txt als »untracked« (nicht verfolgt) markiert ist. Das bedeutet, dass Git diese Datei noch nicht in die Versionskontrolle aufgenommen hat. Bei Git werden Änderungen nicht direkt zum Repository hinzugefügt, sondern zunächst in eine sogenannte »Staging Area« (auch »Index« genannt) kopiert. Verwende den Befehl git add, um die Datei zur Staging Area hinzuzufügen:

git add hello.txt

Überprüfe den Status erneut mit git status:

Die Ausgabe zeigt jetzt, dass die Datei hello.txt in der Staging Area bereitsteht, um committet zu werden.

Einen Commit erstellen

Um die Änderungen dauerhaft im Repository zu speichern, verwende den Befehl git commit. Füge die Option -m hinzu, um eine Commit-Nachricht anzugeben, die beschreibt, was du geändert hast (falls du die Nachricht weglässt, öffnet Git einen Texteditor, in dem du die Nachricht eingeben kannst):

git commit -m "initial commit"

Die Ausgabe zeigt, dass ein neuer Commit erstellt wurde:

Im .git-Verzeichnis ist jetzt ein gerichteter, azyklischer Graph (DAG) entstanden, der mehrere Knoten enthält, wobei jeder Knoten durch eine eindeutige SHA-1-Hash-ID identifiziert wird. Diese Knoten repräsentieren die verschiedenen Objekte in Git: Blobs, Trees und Commits.

• Blob: Der Blob-Knoten mit der SHA1-ID af5626b repräsentiert den Inhalt »Hello, world!« (der Dateiname spielt dabei noch keine Rolle).
• Tree: Der Tree-Knoten mit der SHA1-ID ec947e3 repräsentiert ein Verzeichnis, das die Datei hello.txt enthält, deren Inhalt durch den Blob af5626b repräsentiert wird.
• Commit: Der Commit-Knoten repräsentiert einen Snapshot des Repositories zu einem bestimmten Zeitpunkt. Er verweist auf den Tree ec947e3, der den Zustand des Verzeichnisses zum Zeitpunkt des Commits beschreibt. Der Commit enthält auch Metadaten wie den Autor, das Datum und die Commit-Nachricht.

Zusätzlich gibt es noch zwei Zeiger:

• main: Der Zeiger main zeigt auf den neuesten Commit im main-Branch.
• HEAD: Der Zeiger HEAD zeigt auf den aktuellen Branch (main in diesem Fall). Der daraus resultierende Commit ist der aktuelle Zustand des Repositories, also die Dateien, die sich gerade im Arbeitsverzeichnis befinden.

Die Ausgabe von git status zeigt außerdem an, dass wir keine lokalen Änderungen haben, die noch nicht committet wurden und unser Arbeitsverzeichnis »sauber« ist:

Dateien umbenennen

Benenne die Datei hello.txt in README.md um, indem du den Befehl git mv verwendest:

git mv hello.txt README.md

Erzeuge anschließend einen neuen Commit:

git commit -m "rename hello.txt to README.md"

Die Ausgabe zeigt, dass ein neuer Commit erstellt wurde. Die 100% hinter der Umbenennung sind die Ähnlichkeit, an der Git sie erkannt hat: Der Inhalt ist derselbe geblieben.

Öffne die Datei README.md, ändere world zu planet und füge eine neue Zeile hinzu, sodass in der Datei Folgendes steht:

Hello, planet!

Git is awesome!

Speichere die Datei mit StrgS und überprüfe den Status mit git status im Terminal:

Überprüfe vor jedem Commit, welche Änderungen du vorgenommen hast, indem du den Befehl git diff ausführst:

Du siehst jetzt die aktuellen Änderungen in deinem Arbeitsverzeichnis. Rote Zeilen (-) zeigen entfernte Zeilen an, während grüne Zeilen (+) hinzugefügte Zeilen darstellen.

Wenn du einen Commit erstellen möchtest, der alle Änderungen in deinem Arbeitsverzeichnis umfasst, kannst du den Befehl git commit mit der Option -a verwenden. Diese Option fügt automatisch alle geänderten und gelöschten Dateien zur Staging Area hinzu, bevor der Commit erstellt wird (du sparst dir so git add). Führe den folgenden Befehl aus, um die Änderungen zu committen:

git commit -a -m "updated README.md"

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Wie du sehen kannst, zeigen der main-Branch und HEAD jetzt auf den neuesten Commit, der die Datei README.md mit dem aktualisierten Inhalt enthält. Da der Inhalt verändert wurde, musste ein neuer Blob angelegt werden. Die alten Knoten bleiben weiterhin im Graphen erhalten.

Zeitreise

Lass uns jetzt zu einem früheren Commit zurückkehren. Verwende den Befehl git log, um die Commit-Historie anzuzeigen:

Du siehst eine Liste der Commits, beginnend mit dem neuesten Commit. Passt sie nicht ins Terminal, zeigt Git sie seitenweise, und unten steht ein Doppelpunkt: Mit den Pfeiltasten oder der Leertaste blätterst du weiter, mit q kommst du zurück zur Eingabe. Du siehst außerdem, dass der main-Branch auf den neuesten Commit zeigt und gerade ausgecheckt ist, da auch HEAD auf diesen Commit zeigt.

Wir checken nun eine frühere Version des Repositories aus, nämlich die Version HEAD~2, also zwei Commits vor dem aktuellen HEAD:

git checkout HEAD~2

Hier geht es weiter, sobald du deine Antwort oben abgegeben hast.

Nachdem du einen älteren Commit ausgecheckt hast, befindest du dich in einem sogenannten »detached HEAD«-Zustand. In diesem Zustand zeigt HEAD nicht auf einen Branch, sondern direkt auf einen bestimmten Commit. Das heißt, dass es momentan keinen Branch gibt, der auf diesen Commit zeigt. Änderungen, die du in diesem Zustand vornimmst, werden daher auch nicht automatisch einem Branch zugeordnet. Wenn du später zu einem Branch zurückkehrst, gehen diese Änderungen verloren, sofern du sie nicht vorher in einem neuen Branch speicherst oder du dir die Commit-ID notierst.

Du siehst auch, dass die Datei README.md jetzt wieder hello.txt heißt und den ursprünglichen Inhalt »Hello, world!« hat:

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Du kannst sehen, dass der main-Branch unverändert bleibt und weiterhin auf den neuesten Commit zeigt. Allerdings zeigt HEAD jetzt auf den älteren Commit, den wir ausgecheckt haben (weshalb wir jetzt wieder den ursprünglichen Inhalt des Repositories sehen).

Um wieder zum main-Branch zurückzukehren, kannst du den Befehl git checkout main verwenden:

Damit sind wir wieder im neuesten Zustand des Repositories. Der Git-Objektgraph sieht jetzt wieder folgendermaßen aus:

3. Branches

Kennst du die Situation, in der du eine neue Funktion zu deinem Projekt hinzufügen möchtest, aber nicht sicher bist, ob sie funktioniert? Mit Git kannst du einen neuen Branch erstellen, um an dieser Funktion zu arbeiten, ohne den Haupt-Branch zu beeinflussen. Wenn die Funktion fertig ist und gut funktioniert, kannst du sie wieder in den Haupt-Branch zusammenführen (mergen). Anderenfalls kannst du den Branch einfach löschen, ohne dass dein Haupt-Branch davon betroffen ist.

Einen Branch anlegen

Wir erstellen jetzt einen neuen Branch namens feature und wechseln zu diesem Branch:

git branch feature
git checkout feature

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Es ist also alles wie zuvor, nur dass HEAD jetzt auf den neuen Branch feature zeigt. Erstelle eine neue Datei namens hello.c mit folgendem Inhalt:

1
2
3
4
5
6

#include <stdio.h>

int main() {
    printf("Hello, World!\n");
    return 0;
}

Compiliere die Datei, um ein ausführbares Programm zu erhalten:

gcc -o hello hello.c

…und führe das Programm anschließend aus:

./hello

Du solltest die Meldung Hello, World! im Terminal sehen:

Überprüfe den Status mit git status:

Es sind zwei neue Dateien vorhanden: hello.c und hello (die ausführbare Datei). Wir möchten nur die Quellcodedatei hello.c zur Versionskontrolle hinzufügen, nicht jedoch die ausführbare Datei hello.

Dateien ignorieren

Erstelle eine Datei namens .gitignore mit folgendem Inhalt:

hello

Speichere die Datei und überprüfe den Status erneut mit git status:

Jetzt wird nur noch die Datei hello.c als untracked angezeigt, während die ausführbare Datei hello ignoriert wird. Aber auch die Datei .gitignore selbst ist noch nicht zur Versionskontrolle hinzugefügt worden, was wir unbedingt nachholen sollten. Füge beide Dateien zur Staging Area hinzu:

git add .gitignore hello.c

Erstelle anschließend einen neuen Commit:

git commit -m "added hello.c"

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Wie du sehen kannst, zeigt der feature-Branch jetzt auf den neuesten Commit, der die Dateien hello.c und .gitignore enthält. Der main-Branch bleibt unverändert und zeigt weiterhin auf den vorherigen Commit.

Wir können uns anzeigen lassen, welche Branches es gibt und auf welchen Commit sie zeigen, indem wir den Befehl git branch ausführen:

Wie du siehst, gibt es momentan zwei Branches: main und feature. Der Stern (*) zeigt an, dass wir uns gerade im feature-Branch befinden.

In beiden Branches arbeiten

Wir wechseln jetzt zurück zum main-Branch:

git checkout main

Dort passen wir – unabhängig vom feature-Branch – die Datei README.md an und fügen am Ende einen Smiley hinzu:

Hello, planet!

Git is awesome!

:)

Es ist eine gute Angewohnheit, vor dem Committen die Änderungen mit git diff zu überprüfen:

Wir erstellen jetzt einen neuen Commit:

git commit -a -m "added smiley"

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Branches zusammenführen

Wir könnten uns jetzt dazu entscheiden, die Änderungen aus dem feature-Branch zu verwerfen, indem wir den Branch einfach löschen. In diesem Fall würden die Änderungen an der Datei hello.c verloren gehen, da sie nur im feature-Branch existieren.

Wir möchten die Änderungen aus dem feature-Branch jedoch in den main-Branch übernehmen. Dazu verwenden wir den Befehl git merge, während wir uns im main-Branch befinden. Wie bei git commit gibst du mit -m die Nachricht für den Merge-Commit an; ohne -m öffnet Git dafür einen Editor:

git merge feature -m "merged feature into main"

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Wie du sehen kannst, wurde ein neuer Merge-Commit erstellt, der zwei Vorgänger hat: den vormals neuesten Commit im main-Branch und den neuesten Commit im feature-Branch. Der Merge-Commit kombiniert die Änderungen aus beiden Branches.

Der main-Branch zeigt jetzt auf das aktuelle, vollständige Projekt und wir können den Feature-Branch löschen, da wir ihn nicht mehr benötigen:

git branch -d feature

Der Git-Objektgraph sieht jetzt folgendermaßen aus:

Obwohl es nun keinen feature-Branch mehr gibt, sieht man immer noch Spuren davon im Graphen, da es Verzweigungen und Zusammenführungen in der Versionsgeschichte gibt. Der Vorteil des Feature-Branches war, dass wir isoliert an einer neuen Funktion arbeiten konnten, ohne den Haupt-Branch zu beeinflussen. Nachdem die Funktion fertig war, konnten wir sie problemlos in den Haupt-Branch integrieren.

4. Etwas Luxus im Terminal

Um die Arbeit im Terminal etwas zu vereinfachen, können wir zweierlei tun:

1. Bash-Completion für Git aktivieren
2. Einen Git-Prompt einrichten

Um den Git-Prompt zu installieren, klone das Repository bash-git-prompt in dein Home-Verzeichnis:

git clone https://github.com/magicmonty/bash-git-prompt.git ~/.bash-git-prompt --depth=1

Öffne anschließend die Datei /workspace/.bashrc in VS Code und füge am Ende der Datei folgende Zeilen hinzu:

# enable Bash completion for Git
source /usr/share/bash-completion/completions/git

# enable Git prompt
if [ -f "$HOME/.bash-git-prompt/gitprompt.sh" ]; then
    GIT_PROMPT_ONLY_IN_REPO=1
    GIT_PROMPT_VIRTUALENV=""
    source "$HOME/.bash-git-prompt/gitprompt.sh"
fi

Speichere die Datei und lade die Änderungen mit folgendem Befehl neu:

source ~/.bashrc

Jetzt hast du einen speziellen Git-Prompt, wenn du in einem Git-Repository arbeitest. Dieser Prompt zeigt dir immer den aktuellen Branch und den Status des Repositories an:

Links steht, ob der letzte Befehl geklappt hat (✔), dann das Verzeichnis und in eckigen Klammern der Branch und der Zustand: ✔ heißt, es gibt nichts zu committen. Darunter folgen die Uhrzeit und das $, hinter dem du tippst.

5. Gemeinsam arbeiten

Ein Remote anlegen

In einem echten Projekt arbeitest du wahrscheinlich nicht alleine, sondern im Team. Damit mehrere Personen an demselben Repository arbeiten können, verwenden wir sogenannte »Remotes«. Ein Remote ist eine Kopie deines Repositories, die an einer anderen Stelle – also normalerweise auf einem anderen Computer oder Server – gespeichert ist.

In diesem Tutorial werden wir jedoch anstelle eines Servers einfach ein lokales Verzeichnis verwenden, um das Konzept der Remotes zu demonstrieren – die Handhabung ist in beiden Fällen identisch.

Zuerst legen wir ein neues Verzeichnis namens remote-repo an, das unser Remote-Repository darstellen soll:

cd ~/git-tutorial
mkdir remote-repo
cd remote-repo

In diesem Verzeichnis initialisieren wir ein neues, leeres Git-Repository:

git init --bare

Im Terminal sollte jetzt Folgendes zu sehen sein:

Mit dem Befehl ls -l kannst du sehen, dass in diesem Verzeichnis die üblichen Git-Ordner und -Dateien vorhanden sind, die sonst im .git-Verzeichnis eines normalen Repositories zu finden sind:

Wir wechseln jetzt zurück in das Verzeichnis von Alice, um unser Remote-Repository zu verknüpfen:

cd ~/git-tutorial/alice
git remote add origin ../remote-repo

Der Befehl bewirkt nur, dass das Remote-Repository verknüpft wird, es gibt keine Ausgabe im Terminal. Ein Blick in die Datei .git/config (cat .git/config) zeigt jedoch, dass das Remote-Repository jetzt konfiguriert ist:

Jetzt können wir unsere Änderungen an das Remote-Repository pushen. Verwende den folgenden Befehl, um den main-Branch zum ersten Mal zu pushen:

git push -u origin main

Die Option -u (oder --set-upstream) richtet eine Tracking-Verbindung zwischen dem lokalen main-Branch und dem Remote-Branch origin/main ein. Dadurch kannst du in Zukunft einfach git push oder git pull ausführen, ohne den Remote-Namen und den Branch-Namen angeben zu müssen (ansonsten müsstest du immer git push origin main schreiben).

Bob klont das Repository

Um zu demonstrieren, wie mehrere Personen an demselben Repository arbeiten können, erstellen wir jetzt ein neues Verzeichnis für eine fiktive Person namens Bob:

cd ~/git-tutorial
mkdir bob
cd bob

Bob kann jetzt das Remote-Repository klonen, das wir zuvor erstellt haben:

git clone ../remote-repo

Das Repository wird in ein neues Verzeichnis namens remote-repo geklont. Wechsle in dieses Verzeichnis:

cd remote-repo

Bob hat jetzt eine vollständige Kopie des Repositories, einschließlich der gesamten Versionsgeschichte. Öffne die Datei README.md mit dem Editor nano und ergänze die letzte Zeile, sodass dort :) (Bob was here) steht:

nano README.md

Speichere die Datei mit StrgO und Enter und schließe den Editor mit StrgX. Mit git diff kann Bob seine Änderungen überprüfen:

Wir haben nun drei Möglichkeiten, wie Bob seine Änderungen committen kann:

1. git add README.md und git commit -m "Bob was here"
2. git commit -a -m "Bob was here"
3. git commit -a – bei dieser Variante öffnet sich ein Texteditor, in dem Bob seine Commit-Nachricht eingeben kann.

Um die Änderungen an das Remote-Repository zu senden, verwendet Bob den Befehl git push:

Alice holt Bobs Änderung

Wechsle nun wieder in das Verzeichnis von Alice:

cd ~/git-tutorial/alice

Mit dem Befehl git pull kann Alice die Änderungen von Bob in ihr lokales Repository holen und mit ihrem aktuellen Stand zusammenführen:

Alice sieht mit cat README.md, dass die Datei aktualisiert wurde und jetzt auch Bobs Änderung enthält:

Merge-Konflikte

Wenn Alice und Bob gleichzeitig an derselben Datei arbeiten und ihre Änderungen nicht kompatibel sind, entsteht ein Merge-Konflikt. Um dies zu demonstrieren, ändern wir die Datei README.md sowohl bei Alice als auch bei Bob.

Alice ändert die Datei README.md:

echo "HEYYYY" >> README.md

Überprüfe die Änderungen mit cat und git diff:

Alice committet ihre Änderungen und pusht sie zum Remote-Repository:

git commit -a -m "HEYYYY"
git push

Wechsle jetzt in Bobs Verzeichnis:

cd ~/git-tutorial/bob/remote-repo

Bob ändert ebenfalls die Datei README.md:

echo "HOLAAA" >> README.md

Er überprüft seine Änderungen mit git diff und committet sie:

git diff
git commit -a -m "HOLAAA"

Wenn Bob jetzt versucht, seine Änderungen zu pushen, erhält er eine Fehlermeldung, da Alice bereits Änderungen gepusht hat, die Bob noch nicht in seinem lokalen Repository hat:

Um die Änderungen von Alice zu holen und mit seinen eigenen zusammenzuführen, führt Bob den Befehl git pull aus:

Auch hier erhält Bob eine Fehlermeldung: Sein Branch und der von Alice haben sich auseinanderentwickelt (»divergent branches«), weil beide gleichzeitig an derselben Datei gearbeitet haben. Git möchte wissen, wie es die beiden Stände in Zukunft zusammenführen soll, und bietet drei Strategien an, von denen wir eine als Voreinstellung für unser lokales Repository wählen sollen:

1. git config pull.rebase false – Standard-Merge-Strategie
2. git config pull.rebase true – Rebase-Strategie
3. git config pull.ff only – Nur Fast-Forward-Merges

Bob entscheidet sich für die Standard-Merge-Strategie und führt die folgenden Befehle aus:

git config pull.rebase false
git pull

Wir sehen, dass Git den Merge-Konflikt in der Datei README.md markiert hat. Bob muss die Datei jetzt manuell bearbeiten, um den Konflikt zu lösen. Öffne die Datei README.md in einem Texteditor (nano README.md):

<<<<<<< HEAD

HOLAAA
=======
HEYYYY
>>>>>>> ef91739

Hier siehst du die Konfliktmarkierungen:

<<<<<<< HEAD
HOLAAA
=======
HEYYYY
>>>>>>> ef91739…

Die Markierungen <<<<<<<, ======= und >>>>>>> zeigen die Bereiche an, in denen der Konflikt aufgetreten ist. Der obere Abschnitt enthält Bobs lokale Änderungen, während der untere Abschnitt die Änderungen des Remote-Repository (also Alices Änderungen) enthält. Hinter >>>>>>> steht die ID von Alices Commit.

Bob muss sich jetzt entscheiden, wie er den Konflikt lösen möchte. Er könnte zum Beispiel beide Änderungen durch eine dritte ersetzen und die drei Markierungszeilen löschen, sodass in der Datei Folgendes steht:

Hello, planet!

Git is awesome!

:) (Bob was here)
BONJOUR!

Speichere die Datei und beende den Editor. Bob muss den Konflikt nun als gelöst markieren, indem er die Datei mit git add zur Staging Area hinzufügt. Anschließend kann er den Merge-Commit, der durch den Pull-Vorgang erstellt wurde und zunächst aufgrund des Konflikts unvollständig war, abschließen und danach seine Änderungen pushen:

git add README.md
git commit -m "fixed merge conflict"
git push

Alice hat von dem Merge-Konflikt nichts mitbekommen, da Bob den Konflikt lokal gelöst hat, bevor er seine Änderungen gepusht hat. Wenn Alice jetzt ihre Änderungen mit git pull holt, erhält sie die von Bob aktualisierte Datei README.md.

6. Nützlich für später

Tags

Tags sind eine Möglichkeit, bestimmte Punkte in der Versionsgeschichte zu markieren, z.B. für Releases oder wichtige Meilensteine. Wir erstellen jetzt einen Tag namens v1.0 für den aktuellen Commit im main-Branch:

git tag -a v1.0 -m "v1.0 release"

Mit git log --oneline --graph siehst du die ganze Geschichte auf einen Blick, mit dem Tag und den Verzweigungen, die Alice und Bob hinterlassen haben:

So können wir später leicht zu diesem Punkt in der Geschichte zurückkehren, wenn wir z.B. ein Release erstellen möchten. Um Tags zu pushen, verwenden wir den Befehl git push mit dem Tag-Namen:

git push origin v1.0

…oder um alle Tags auf einmal zu pushen:

git push origin --tags

Zu einem Stand springen

Um zu einem bestimmten Branch oder Tag zurückzukehren, verwenden wir den Befehl git checkout. Du kannst also z. B. folgende Befehle verwenden:

• git checkout main – wechselt zum main-Branch
• git checkout v1.0 – wechselt zum Tag v1.0
• git checkout HEAD~2 – wechselt zu dem Commit, der zwei Commits vor dem aktuellen HEAD liegt

Fehler rückgängig machen

Manchmal möchtest du vielleicht Änderungen an Dateien rückgängig machen. Welcher Befehl passt, hängt davon ab, wie weit die Änderung schon gekommen ist:

7. Zusammenfassung

Mit diesem Wissen kannst du Git für deine eigenen Projekte nutzen. Zum Nachschlagen stehen diese Befehle und ein paar weitere im Handbuch unter Git: Versionen verwalten. Wie du mit einem Git-Server wie GitLab, Gitea oder GitHub arbeitest, steht im Handbuch unter Git-Server: Zugang und Veröffentlichen.

Pro Git, Scott Chacon und Ben Straub, Apress, 2. Auflage 2014. Alles, was hier fehlt: Rebase, Git auf einem Server, die Arbeit mit GitHub und wie Git seine Commits intern speichert. Frei lesbar, auch auf Deutsch: auf git-scm.com.

Cover: Apress, CC BY-NC-SA 3.0 (progit2)