Kapitel 3. Praktische Versionsverwaltung

Eine Referenz, die Sie selten explizit, aber ständig implizit benutzen, ist HEAD. Sie referenziert meist den gerade ausgecheckten Branch, hier master:

$ cat .git/HEAD
ref: refs/heads/master

HEAD kann auch direkt auf einen Commit zeigen, wenn Sie git checkout <commit-id> eingeben. Sie sind dann allerdings im sogenannten Detached-Head-Modus, in dem Commits möglicherweise verlorengehen, siehe auch Abschnitt 3.2.1, „Detached HEAD“.

Der HEAD bestimmt, welche Dateien im Working Tree zu finden sind, welcher Commit Vorgänger bei der Erstellung eines neuen wird, welcher Commit per git show angezeigt wird etc. Wenn wir hier von „dem aktuellen Branch“ sprechen, dann ist damit technisch korrekt der HEAD gemeint.

Die simplen Kommandos log, show und diff nehmen ohne weitere Argumente HEAD als erstes Argument an. Die Ausgabe von git log ist gleich der von git log HEAD usw. – dies gilt für die meisten Kommandos, die auf einem Commit operieren, wenn Sie keinen explizit angeben. HEAD ist somit vergleichbar mit der Shell-Variable PWD, die angibt „wo man ist“.

Wenn wir von einem Commit sprechen, dann ist es einem Kommando in der Regel egal, ob man die Commit-ID komplett oder verkürzt angibt oder den Commit über eine Referenz, wie z.B. ein Tag oder Branch, ansteuert. Eine solche Referenz muss aber nicht immer eindeutig sein. Was passiert, wenn es einen Branch master gibt und ein Tag gleichen Namens? Git überprüft, ob die folgenden Referenzen existieren:

Die erste gefundene Referenz nimmt Git als Treffer an. Sie sollten also Tags immer ein eindeutiges Schema geben, um sie nicht mit Branches zu verwechseln. So können Sie Branches direkt über den Namen statt über heads/<name> ansprechen.

Besonders wichtig sind dafür die Suffixe ^ und ~<n>. Die Syntax <ref>^ bezeichnet den direkten Vorfahren von <ref>. Dieser muss aber nicht immer eindeutig sein: Wenn zwei oder mehr Branches zusammengeführt wurden, hat der Merge-Commit mehrere direkte Vorfahren. <ref>^ bzw. <ref>^1 bezeichnen dann den ersten direkten Vorfahren, <ref>^2 den zweiten usw.^[30] Die Syntax HEAD^^ bedeutet also „der zwei Ebenen vorher liegende direkte Vorfahre des aktuellen Commits“. Achten Sie darauf, dass ^ in Ihrer Shell möglicherweise eine spezielle Bedeutung hat und Sie es durch Anführungszeichen oder mit einem Backslash schützen müssen.

Abbildung 3.3. Relative-Referenzen, ^ und ~<n>

Die Syntax <ref>~<n> kommt einer n-fachen Wiederholung von ^ gleich: HEAD~10 bezeichnet also den zehnten direkten Vorgänger des aktuellen Commits. Achtung: Das heißt nicht, dass zwischen HEAD und HEAD~10 nur elf Commits liegen: Da ^ bei einem etwaigen Merge nur dem ersten Strang folgt, liegen zwischen den beiden Referenzen die elf und alle durch einen Merge integrierten weiteren Commits. Die Syntax ist übrigens in der Man-Page git-rev-parse(1) im Abschnitt „Specifying Revisions“ dokumentiert.

Ein Branch ist in Git im Nu erstellt. Git muss lediglich den aktuell ausgecheckten Commit identifizieren und die SHA-1-Summe in der Datei .git/refs/heads/<branch-name> ablegen.

$ time git branch neuer-branch
git branch neuer-branch  0.00s user 0.00s system 100% cpu 0.008 total

Das Kommando ist so schnell, weil (im Gegensatz zu anderen Systemen) keine Dateien kopiert und keine weiteren Metadaten abgelegt werden müssen. Informationen über die Struktur der Versionsgeschichte sind immer aus dem Commit, den ein Branch referenziert, und seinen Vorfahren ableitbar.

Hier eine Übersicht der wichtigsten Optionen:

$ git checkout master
A   neue-datei.txt
Switched to branch master

$ git branch -D test
Deleted branch test (was e32bf29).
$ git branch test e32bf29

SHA-1-Summen sind zwar eine sehr elegante Lösung, um Versionen dezentral zu beschreiben, aber semantikarm und für Menschen unhandlich. Im Gegensatz zu linearen Revisionsnummern sagen uns Commit-IDs allein nichts über die Reihenfolge der Versionen.

Während der Entwicklung von Softwareprojekten müssen verschiedene „wichtige“ Versionen so markiert werden, dass sie leicht in dem Repository zu finden sind. Die wichtigsten sind meist solche, die veröffentlicht werden, die sogenannten Releases. Auch Release Candidates werden häufig auf diese Weise markiert, also Versionen, die die Basis für die nächste Version bilden und im Zuge der Qualitätssicherung auf kritische Fehler untersucht werden, ohne dass neue Features hinzugefügt werden. Je nach Projekt und Entwicklungsmodell gibt es verschiedene Konventionen, um Releases zu bezeichnen, und Abläufe, wie sie vorbereitet und publiziert werden.

Im Open-Source-Bereich haben sich zwei Versionierungsschemata durchgesetzt: die klassische Major/Minor/Micro-Versionierung und neuerdings auch die datumsbasierte Versionierung. Bei der Major/Minor/Micro-Versionierung, welche z.B. beim Linux-Kernel und auch Git eingesetzt wird, ist eine Version durch drei (oft auch vier) Zahlen gekennzeichnet: 2.6.39 oder 1.7.1. Bei der datumsbasierten Versionierung hingegen ist die Bezeichnung aus dem Zeitpunkt des Releases abgeleitet, z.B.: 2011.05 oder 2011-05-19. Das hat den großen Vorteil, dass das Alter einer Version leicht ersichtlich ist.^[33]

Git bietet Ihnen mit Tags („Etiketten“) die Möglichkeit, beliebige Git-Objekte – meist Commits – zu markieren, um markante Zustände in der Entwicklungsgeschichte hervorzuheben. Tags sind, wie Branches auch, als Referenzen auf Objekte implementiert. Im Gegensatz zu Branches jedoch sind Tags statisch, das heißt, sie werden nicht verschoben, wenn neue Commits hinzukommen, und zeigen stets auf dasselbe Objekt. Es gibt zwei Arten von Tags: Annotated (mit Anmerkungen versehen) und Lightweight („leichtgewichtig“, d.h. ohne Anmerkungen). Annotated Tags sind mit Metadaten – z.B. Autor, Beschreibung oder GPG-Signatur – versehen. Lightweight Tags zeigen hingegen „einfach nur“ auf ein bestimmtes Git-Objekt. Für beide Arten von Tags legt Git unter .git/refs/tags/ bzw. .git/packed-refs Referenzen an. Der Unterschied ist, dass Git für jedes Annotated Tag ein spezielles Git-Objekt – und zwar ein Tag-Objekt – in der Objektdatenbank anlegt, um die Metadaten sowie die SHA-1-Summe des markierten Objekts zu speichern, während ein Lightweight Tag direkt auf das markierte Objekt zeigt. Abbildung 3.4, „Das Tag-Objekt“ zeigt den Inhalt eines Tag-Objekts; vergleichen Sie auch die anderen Git-Objekte, Abbildung 2.4, „Git-Objekte“.

Abbildung 3.4. Das Tag-Objekt

Das gezeigte Tag-Objekt hat sowohl eine Größe (158 Byte) als auch eine SHA-1-Summe. Es enthält die Bezeichnung (0.1), den Objekt-Typ und die SHA-1-Summe des referenzierten Objekts sowie den Namen und E-Mail des Autors, der im Git-Jargon Tagger heißt. Außerdem enthält das Tag eine Tag-Message, die zum Beispiel die Version beschreibt, sowie optional eine GPG-Signatur. Im Git-Projekt etwa besteht eine Tag-Message aus der aktuellen Versionsbezeichnung und der Signatur des Maintainers.

Schauen wir im Folgenden zunächst, wie Sie Tags lokal verwalten. Wie Sie Tags zwischen Repositories austauschen, beschreibt Abschnitt 5.8, „Tags austauschen“.

Tags verwalten

Tags verwalten Sie mit dem Kommando git tag. Ohne Argumente zeigt es alle vorhandenen Tags an. Je nach Projektgröße lohnt es sich, die Ausgabe mit der Option -l und einem entsprechenden Muster einzuschränken. Mit folgendem Befehl zeigen Sie alle Varianten der Version 1.7.1 des Git-Projekts an, also sowohl die Release-Candidates mit dem Zusatz -rc* sowie die (vierstelligen) Maintenance-Releases:

$ git tag -l v1.7.1*
v1.7.1
v1.7.1-rc0
v1.7.1-rc1
v1.7.1-rc2
v1.7.1.1
v1.7.1.2
v1.7.1.3
v1.7.1.4

Den Inhalt eines Tags liefert Ihnen git show:

$ git show 0.1 | head
tag 0.1
Tagger: Valentin Haenel <valentin.haenel@gmx.de>
Date:   Wed Mar 23 16:52:03 2011 +0100

Erste Veröffentlichung

commit e2c67ebb6d2db2aab831f477306baa44036af635
Author: Valentin Haenel <valentin.haenel@gmx.de>
Date:   Sat Jan 8 20:30:58 2011 +0100

Gitk stellt Tags als gelbe, pfeilartige Kästchen dar, die sich deutlich von den grünen, rechteckigen Branches unterscheiden:

Abbildung 3.5. Tags in Gitk

$ git tag api-aenderung
$ git tag
api-aenderung

$ git tag pre-regression HEAD~23
$ git tag
api-aenderung
pre-regression

$ git tag pre-regression
fatal: tag 'pre-regression' already exists

$ git tag -m "Zweite Veröffentlichung" 0.2

$ git tag -v v1.7.1
object d599e0484f8ebac8cc50e9557a4c3d246826843d
type commit
tag v1.7.1
tagger Junio C Hamano <gitster@pobox.com> 1272072587 -0700

Git 1.7.1
gpg: Signature made Sat Apr 24 03:29:47 2010 CEST using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <junkio@cox.net>"
...

$ git config --global user.signingkey <GPG-Key-ID>

$ git tag -s -m "Dritte Veröffentlichung" 3.0

$ git tag -d 0.2
Deleted tag '0.2' (was 4773c73)

$ git show junio-gpg-pub | head -5
tag junio-gpg-pub
Tagger: Junio C Hamano <junkio@cox.net>
Date:   Tue Dec 13 16:33:29 2005 -0800

GPG key to sign git.git archive.

$ git cat-file blob junio-gpg-pub | gpg --import
gpg: key F3119B9A: public key "Junio C Hamano <junkio@cox.net>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Commits beschreiben

Tags sind sehr nützlich, um beliebige Commits „besser“ zu beschreiben. Das Kommando git describe gibt eine Beschreibung, die aus dem aktuellsten Tag und dessen relativer Position im Commit-Graphen besteht. Hier ein Beispiel aus dem Git-Projekt: Wir beschreiben einen Commit mit dem SHA-1-Präfix 28ba96a, der sich im Commit-Graphen sieben Commits nach der Version 1.7.1 befindet:

Abbildung 3.6. Der zu beschreibende Commit in Grau hervorgehoben

$ git describe --tags
v1.7.1-7-g28ba96a

Die Ausgabe von git describe ist wie folgt formatiert:

<tag>-<position>-g<SHA-1>

Das Tag ist v1.7.1; die Position besagt, dass sich sieben neue Commits zwischen dem Tag und dem beschriebenen Commit befinden.^[35] Das Kürzel g vor der ID besagt, dass die Beschreibung aus einem Git-Repository abgeleitet ist, was in Umgebungen mit mehreren Versionsverwaltungssystemen nützlich ist. Standardmäßig sucht git describe nur nach Annotated Tags, mit der Option --tags erweitern Sie die Suche auch auf Lightweight Tags.

Das Kommando ist sehr nützlich, weil es einen inhaltsbasierten Bezeichner in etwas für Menschen Sinnvolles übersetzt: v1.7.1-7-g28ba96a ist deutlich näher an v1.7.1 als v1.7.1-213-g3183286. Dadurch können Sie die Ausgaben sinnvoll – wie im Git-Projekt auch – direkt in die Software einkompilieren:

$ git describe
v1.7.5-rc2-8-g0e73bb4
$ make
GIT_VERSION = 1.7.5.rc2.8.g0e73bb
...
$ ./git --version
git version 1.7.5.rc2.8.g0e73bb

Somit weiß ein Benutzer ungefähr, welche Version er hat, und kann nachvollziehen, aus welchem Commit die Version kompiliert wurde.

Wenn Sie einen Commit auschecken, der nicht durch einen Branch referenziert wird, befinden Sie sich im sogenannten Detached-HEAD-Modus:

$ git checkout 3329661
Note: checking out '3329661'.

You are in 'detached HEAD' state. You can look around, make
experimental changes and commit them, and you can discard any
commits you make in this state without impacting any branches
by performing another checkout.

If you want to create a new branch to retain commits you create,
you may do so (now or later) by using -b with the checkout command
again. Example:

  git checkout -b new_branch_name

HEAD is now at 3329661... Add LICENSE file

Wie die Erklärung, die Sie durch setzen der Option advice.detachedHead auf false ausblenden können, schon warnt, werden Änderungen, die Sie nun tätigen, im Zweifel verlorengehen: Da Ihr HEAD danach die einzige direkte Referenz auf den Commit ist, werden weitere Commits nicht direkt von einem Branch referenziert (sie sind unreachable, s.o.).

Im Detached-HEAD-Modus zu arbeiten bietet sich also vor allem dann an, wenn Sie schnell etwas probieren wollen: Ist der Fehler eigentlich schon im Commit 3329661 aufgetaucht? Gab es zum Zeitpunkt von 3329661 eigentlich schon die Datei README?

$ git checkout -b <temp-branch>

Wenn Sie alle Änderungen, die ein Commit einbringt, rückgängig machen wollen, hilft das Kommando revert. Es löscht aber keinen Commit, sondern erstellt einen neuen, dessen Änderungen genau dem Gegenteil des anderen Commits entsprechen: Gelöschte Zeilen werden zu hinzugefügten und umgekehrt.

Angenommen, Sie haben einen Commit, der eine Datei LICENSE erstellt. Der Patch des entsprechenden Commits sieht so aus:

--- /dev/null
+++ b/LICENSE
@@ -0,0 +1 @@
+This software is released under the GNU GPL version 3 or newer.

Nun können Sie die Änderungen rückgängig machen:

$ git revert 3329661
Finished one revert.
[master a68ad2d] Revert "Add LICENSE file"
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100644 LICENSE

Git erstellt einen neuen Commit auf dem aktuellen Branch – sofern Sie nichts anderes angeben – mit der Beschreibung Revert "<Alte Commit-Nachricht>". Dieser Commit sieht so aus:

$ git show
commit a68ad2d41e9219383449d703521573477ee7da48
Author: Julius Plenz <feh@mali>
Date:   Mon Mar 7 05:28:47 2011 +0100

    Revert "Add LICENSE file"

    This reverts commit 3329661775af3c52e6b2ad7e9e7e7d789ba62712.

diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index 3fd9c20..0000000
--- a/LICENSE
+++ /dev/null
@@ -1 +0,0 @@
-This software is released under the GNU GPL version 3 or newer.

Beachten Sie also, dass in der Versionsgeschichte eines Projekts ab nun sowohl der Commit als auch der Revert auftauchen. Sie machen also nur die Änderungen rückgängig, löschen aber keine Informationen aus der Versionsgeschichte.

Sie sollten daher revert nur einsetzen, wenn Sie eine Änderung, die bereits veröffentlicht wurde, rückgängig machen müssen. Entwickeln Sie allerdings lokal in einem eigenen Branch, ist es sinnvoller, diese Commits komplett zu löschen (siehe dafür den folgenden Abschnitt über reset sowie das Thema Rebase, Abschnitt 4.1, „Commits verschieben – Rebase“).

Sofern Sie einen Revert durchführen wollen, allerdings nicht für sämtliche Änderungen des Commits, sondern nur für die einer Datei, können Sie sich zum Beispiel so behelfen:

$ git show -R 3329661 -- LICENSE | git apply --index
$ git commit -m 'Revert change to LICENSE from 3329661'

Das Kommando git show gibt die Änderungen von Commit 3329661 aus, die sich auf die Datei LICENSE beziehen. Die Option -R sorgt dafür, dass das Unified-Diff-Format „andersherum“ angezeigt wird (reverse). Die Ausgabe wird an git apply weitergeleitet, um die Änderungen an der Datei und dem Index vorzunehmen. Anschließend werden die Änderungen eingecheckt.

Eine weitere Möglichkeit, eine Änderung rückgängig zu machen, besteht darin, eine Datei aus einem vorherigen Commit auszuchecken, sie dem Index hinzuzufügen und neu einzuchecken:

$ git checkout 3329661 -- <datei>
$ git add <datei>
$ git commit -m 'Reverting <datei> to resemble 3329661'

Wenn Sie einen Commit gänzlich löschen, also nicht nur rückgängig machen, dann verwenden Sie git reset. Das Reset-Kommando setzt den HEAD (und damit auch den aktuellen Branch) sowie wahlweise auch Index und Working Tree auf einen bestimmten Commit. Die Syntax lautet git reset [<option>] [<commit>].

Die wichtigsten Reset-Typen sind die folgenden:

Wenn Sie git reset ohne Optionen aufrufen, entspricht dies einem git reset --mixed HEAD. Das Kommando haben wir schon kennengelernt: Git setzt den aktuellen HEAD auf HEAD (verändert ihn also nicht) und den Index auf HEAD – dabei gehen die vorher hinzugefügten Änderungen verloren.

Die Anwendungsmöglichkeiten dieses Kommandos sind vielfältig und werden in den verschiedenen Kommandosequenzen wieder auftauchen. Daher ist es wichtig, die Funktionalität zu verstehen, auch wenn es teilweise alternative Kommandos gibt, die den gleichen Effekt haben.

Angenommen, Sie haben auf master zwei Commits gemacht, die Sie eigentlich auf einen neuen Branch verschieben wollen, um noch weiter daran zu arbeiten. Die folgende Kommandosequenz erstellt einen neuen Branch, der auf den HEAD zeigt, und setzt anschließend HEAD und damit den aktuellen Branch master zwei Commits zurück. Dann checken Sie den neuen Branch <neues-feature> aus.

$ git branch <neues-feature>
$ git reset --hard HEAD^^
$ git checkout <neues-feature>

Alternativ hat die folgende Sequenz den gleichen Effekt: Sie erstellen einen Branch <neues-feature>, der auf den aktuellen Commit zeigt. Dann löschen Sie master und erstellen ihn neu, so dass er auf den zweiten Vorgänger des aktuellen Commits zeigt.

$ git checkout -b <neues-feature>
$ git branch -D master
$ git branch master HEAD^^

$ git reset --hard HEAD^^
$ git checkout -b <neues-feature> ORIG_HEAD

$ git checkout -b <reorder-feature> <feature>
$ git reset master
$ git add -p
$ git commit
$ ...

$ git commit -m 'feature (noch unfertig)'
(später)
$ git reset --soft HEAD^
(weiterarbeiten)

Die zwei Branches topic und master, die Sie mergen wollen, referenzieren jeweils den aktuellsten Commit in einer Kette von Commits (F und D), und diese beiden Commits wiederum einen Tree (entspricht dem obersten Verzeichnis Ihres Projekts).

Zunächst berechnet Git eine sogenannte Merge-Basis, also einen Commit, den beide zu verschmelzenden Commits als gemeinsamen Vorfahren haben. In der Regel gibt es mehrere solcher Basen – im untenstehenden Diagramm A und B – , dann wird die neueste (die also die anderen Basen als Vorfahren hat) verwendet.^[37] Anschaulich gesprochen, ist dies für einfache Fälle der Commit, an dem die Branches divergiert haben (also B).

Wenn Sie nun zwei Commits miteinander verschmelzen wollen (D und F zu M), dann müssen also die von den Commits referenzierten Trees verschmolzen werden.

Abbildung 3.7. Merge-Basis und Merge-Commit

Dafür geht Git so vor:^[38] Wenn ein Tree-Eintrag (ein weiterer Tree oder ein Blob) in beiden Commits gleich ist, wird genau dieser Tree-Eintrag auch im Merge-Commit übernommen. Das passiert in zwei Fällen:

Wenn ein Tree-Eintrag in einem der Commits verschwindet, im anderen aber noch vorhanden ist und der gleiche ist wie in der Merge-Basis, dann wird er nicht übernommen. Das entspricht dem Löschen einer Datei oder eines Verzeichnisses, wenn an der Datei auf der anderen Seite keine Änderungen vorgenommen wurden. Analog, wenn ein Commit einen neuen Tree-Eintrag mitbringt, wird dieser in den Merge-Tree übernommen.

Was passiert nun, wenn eine Datei aus den Commits verschiedene Blobs aufweist, die Datei also zumindest auf der einen Seite verändert wurde? Im Falle, dass einer der Blobs der gleiche ist wie in der Merge-Basis, wurden nur auf einer Seite Änderungen an der Datei durchgeführt – Git kann diese Änderungen also einfach übernehmen.

Wenn sich aber beide Blobs von der Merge-Basis unterscheiden, könnte es möglicherweise zu Problemen kommen. Zunächst versucht Git, die Änderungen beider Seiten zu übernehmen.

Dafür wird in der Regel ein 3-Wege-Merge-Algorithmus verwendet. Im Gegensatz zum klassischen 2-Wege-Merge-Algorithmus, der eingesetzt wird, wenn Sie zwei unterschiedliche Versionen A und B einer Datei haben und diese zusammenführen wollen, bezieht dieser 3-Wege-Algorithmus eine dritte Version C der Datei ein, extrahiert aus obiger Merge-Basis. Der Algorithmus kann daher, weil ein gemeinsamer Vorgänger der Datei bekannt ist, in vielen Fällen besser (d.h. nicht nur anhand der Zeilennummer bzw. des Kontextes) entscheiden, wie Änderungen zusammengeführt werden. In der Praxis werden so viele trivial lösbare Merge-Konflikte schon automatisch ohne Zutun des Nutzers gelöst.

Es gibt allerdings Konflikte, die kein noch so guter Merge-Algorithmus zusammenführen kann. Das passiert zum Beispiel, wenn in Version A der Datei der Kontext direkt vor einer Änderung in Datei B geändert wurde, oder, schlimmer noch, Version A und B und C unterschiedliche Versionen einer Zeile aufweisen.

Einen solchen Fall nennt man Merge-Konflikt. Git führt alle Dateien so gut es geht zusammen und präsentiert dem Nutzer dann die in Konflikt stehenden Änderungen, damit dieser sie manuell verschmelzen (und damit den Konflikt lösen) kann (siehe dafür Abschnitt 3.4, „Merge-Konflikte lösen“).

Zwar ist es grundsätzlich möglich, mit einem speziell auf die jeweilige Programmiersprache ausgerichteten Algorithmus eine syntaktisch korrekte Auflösung zu erzeugen – allerdings kann ein Algorithmus nicht hinter die Semantik des Codes schauen, also die Bedeutung des Codes erfassen. Daher wäre eine so generierte Lösung in der Regel nicht sinnvoll.

Das Kommando git merge erzeugt nicht immer einen Merge-Commit. Ein trivialer Fall, der aber häufig vorkommt, ist der sogenannte Fast-Forward-Merge, also ein Vorspulen des Branches.

Ein Fast-Forward-Merge tritt dann auf, wenn ein Branch, z.B. topic, Kind eines zweiten Branches, master, ist:

Abbildung 3.8. Vor dem Fast-Forward-Merge

Ein einfaches git merge topic im Branch master führt nun dazu, dass master einfach weitergerückt wird – es wird kein Merge-Commit erzeugt.

Abbildung 3.9. Nach dem Fast-Forward-Merge – es wurde kein Merge-Commit erzeugt

Ein solches Verhalten geht natürlich nur dann, wenn die beiden Branches nicht divergiert haben, wenn also die Merge-Basis beider Branches einer der beiden Branches selbst ist, in diesem Falle master.

Dieses Verhalten ist häufig wünschenswert:

Es gibt verschiedene Meinungen, ob man Änderungen immer per Fast-Forward integrieren sollte oder lieber einen Merge-Commit erstellt, obwohl dies nicht unbedingt nötig ist. Die Resultate sind in beiden Fällen gleich: Die Änderungen aus einem Branch werden in einen anderen integriert.

Wenn Sie allerdings einen Merge-Commit erstellen, dann wird die Integration eines Features deutlich. Betrachten Sie die beiden folgenden Ausschnitte aus der Versionsgeschichte eines Projekts:

Abbildung 3.10. Integration eines Features mit und ohne Fast-Forward

Im oberen Fall können Sie nicht ohne weiteres erkennen, welche Commits ehemals im Branch sha1-caching entwickelt wurden, also mit einem spezifischen Feature der Software zu tun haben.

In der unteren Version jedoch können Sie auf den ersten Blick erkennen, dass es genau vier Commits auf diesem Branch gab und er dann integriert wurde. Da parallel nichts entwickelt wurde, wäre der Merge-Commit prinzipiell unnötig, allerdings macht er die Integration des Features deutlich.

nfm = merge --no-ff     # no-ff-merge
ffm = merge --ff-only   #    ff-merge

Ein expliziter Merge-Commit ist auch hilfreich, weil Sie diesen mit einem einzigen Kommando rückgängig machen können. Dies ist beispielsweise dann sinnvoll, wenn Sie einen Branch integriert haben, der aber Fehler aufweist: Wenn der Code in Produktion läuft, ist es häufig wünschenswert, die gesamte Änderung vorerst wieder auszubauen, bis der Fehler korrigiert ist. Verwenden Sie dafür:

git revert -m 1 <merge-commit>

Git produziert dann einen neuen Commit, der alle Änderungen rückgängig macht, die durch den Merge verursacht wurden. Die Option -m 1 gibt hier an, welche „Seite“ des Merges als Mainline, also stabile Entwicklungslinie, gelten soll: deren Änderungen bleiben bestehen. Im obigen Beispiel würde -m 1 dazu führen, dass die Änderungen der vier Commits aus dem Branch sha1-caching, also dem zweiten Strang des Merges, rückgängig gemacht würden.

Git kennt fünf verschiedene Merge-Strategien, deren Verhalten teilweise noch durch Strategie-Optionen weiter angepasst werden kann. Die Strategie bestimmen Sie per -s, so dass ein Merge-Aufruf wie folgt lautet:

git merge -s <strategie> <branch>

Manche dieser Strategien können nur zwei Branches zusammenführen, andere eine beliebige Anzahl.

Die Default-Strategie recursive kennt mehrere Optionen, die das Verhalten besonders bezüglich der Konfliktlösung anpassen. Sie bestimmen sie über die Option -X; die Syntax lautet also:

git merge -s recursive -X <option> <branch>

Sofern Sie nur zwei Branches mergen, müssen Sie die recursive-Strategie nicht explizit per -s recursive angeben.

Da die Strategie nur zwei Branches zusammenführen kann, ist es möglich, von unserer (engl. our) und deren (engl. theirs) Version zu sprechen: unsere Version ist dabei der ausgecheckte Branch beim Merge-Vorgang, während deren Version den Branch, den Sie integrieren wollen, referenziert.

Bei nicht-trivialen Merge-Konflikten empfiehlt sich ein Merge-Tool, das die drei Stufen einer Datei entsprechend visualisiert und dadurch die Lösung des Konflikts erleichtert.

Gängige IDEs und Editoren wie z.B. Vim und Emacs bieten einen solchen Modus an. Außerdem gibt es externe Tools, wie zum Beispiel KDiff3⁠^[41] und Meld⁠^[42]. Letzteres visualisiert besonders gut, wie sich eine Datei zwischen den Commits verändert hat.

Abbildung 3.11. Der Beispiel-Merge-Konflikt, im Merge-Tool „Meld“ visualisiert

Sie starten ein solches Merge-Tool über git mergetool. Git wird alle Dateien, die Konflikte enthalten, durchgehen und jeweils (wenn Sie Eingabe drücken) in einem Merge-Tool anzeigen. Per Default ist das Vimdiff^[43].

Ein solches Programm wird in der Regel die drei Versionen einer Datei – unsere Seite, deren Seite sowie die soweit wie möglich zusammengeführte Datei inklusive Konflikt-Markern – in drei Spalten nebeneinander anzeigen, letztere sinnvollerweise in der Mitte. Wesentlich ist immer, dass Sie die Änderung (Konfliktlösung) in der mittleren Datei machen, also auf der Working-Copy. Die anderen Dateien sind temporär und werden wieder gelöscht, wenn das Merge-Tool beendet wurde.

Prinzipiell können Sie ein beliebiges anderes Tool verwenden. Das mergetool-Script legt lediglich die drei Stufen der Datei mit entsprechendem Dateinamen ab und startet das Diff-Tool auf diesen drei Dateien. Beendet sich das Programm wieder, überprüft Git, ob noch Konflikt-Marker in der Datei enthalten sind – wenn nicht, wird Git annehmen, dass der Konflikt erfolgreich gelöst wurde, und die Datei automatisch per git add dem Index hinzufügen. Wenn Sie also alle Dateien abarbeiten, müssen Sie schließlich nur noch einen Commit-Aufruf ausführen, um die Konfliktlösung zu besiegeln.

Welches Tool Git auf der Datei startet, regelt die Option merge.tool. Die folgenden Kommandos sind bereits vorkonfiguriert, d.h. Git weiß bereits, in welcher Reihenfolge das Programm die Argumente erwartet und welche Zusatzoptionen angegeben werden müssen:

araxis bc3 codecompare deltawalker diffmerge diffuse
ecmerge emerge gvimdiff gvimdiff2 gvimdiff3 kdiff3
meld opendiff p4merge tkdiff tortoisemerge
vimdiff vimdiff2 vimdiff3 xxdiff

Um Ihr eigenes Merge-Tool zu verwenden, müssen Sie merge.tool auf einen geeigneten Namen setzen, zum Beispiel mymerge, und anschließend zumindest die Option mergetool.mymerge.cmd angeben. Den darin gespeicherten Ausdruck wertet die Shell aus, und die Variablen BASE, LOCAL, REMOTE sowie MERGED, die die Datei mit den Konflikt-Markern enthält, sind auf die entsprechend erzeugten temporären Dateien gesetzt. Sie können die Eigenschaften Ihres Merge-Kommandos weiter konfigurieren, siehe dafür die Man-Page git-config(1) im Abschnitt der mergetool-Konfiguration.

Git besitzt ein relativ unbekanntes (und schlecht dokumentiertes), aber sehr hilfreiches Feature: Rerere, kurz für Reuse Recorded Resolution („gespeicherte Konfliktlösung wiederverwenden“). Sie müssen die Option rerere.enabled auf true setzen, damit das Kommando automatisch aufgerufen wird (beachten Sie das d am Ende von enabled).

Die Idee hinter Rerere ist simpel, aber effektiv: Sobald ein Merge-Konflikt auftritt, nimmt Rerere automatisch ein Preimage auf, ein Abbild der Konfliktdatei inklusive Markern. Im Falle des obigen Beispiels sähe das so aus:

$ git merge B
Auto-merging output.c
CONFLICT (content): Merge conflict in output.c
Recorded preimage for 'output.c'
Automatic merge failed; fix conflicts and then commit the result.

Wird der Konflikt wie oben gelöst und die Lösung eingecheckt, speichert Rerere die Konfliktlösung ab:

$ vim output.c
$ git add output.c
$ git commit
Recorded resolution for 'output.c'.
[master 681acc2] Merge branch 'B'

Bisher hat Rerere noch nicht wirklich geholfen. Jetzt aber können wir den Merge-Commit komplett löschen (und sind wieder in der Ausgangssituation vor dem Merge). Dann führen wir den Merge noch einmal aus:

$ git reset --hard HEAD^
HEAD is now at f894659 wrap output at 72 chars
$ git merge B
Auto-merging output.c
CONFLICT (content): Merge conflict in output.c
Resolved 'output.c' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.

Rerere bemerkt, dass der Konflikt bekannt ist und dass bereits eine Lösung gefunden wurde.^[44] Also berechnet Rerere einen 3-Wege-Merge zwischen dem gespeicherten Preimage, der gespeicherten Lösung und der im Working Tree vorliegenden Version der Datei. So kann Rerere nicht nur dieselben Konflikte lösen, sondern auch ähnliche (wenn zwischenzeitlich weitere Zeilen außerhalb des Konfliktbereichs geändert wurden).

Das Ergebnis wird nicht direkt dem Index hinzugefügt. Die Lösung wird lediglich in die Datei übernommen. Sie können dann per git diff nachschauen, ob die Lösung sinnvoll aussieht, eventuell Tests laufen lassen etc. Wenn alles gut aussieht, übernehmen Sie wie üblich die automatische Lösung per git add.

Dezentrale Versionskontrollsysteme verwalten Merges generell wesentlich besser als zentrale. Das liegt vor allem daran, dass es bei dezentralen Systemen Usus ist, viele kleine Änderungen zunächst lokal einzuchecken. Dadurch entstehen keine „Monster-Commits“, die wesentlich mehr Konfliktpotential bieten. Diese feiner granulierte Entwicklungsgeschichte und der Umstand, dass Merges in der Regel wiederum Daten in der Versionsgeschichte sind (im Gegensatz zu einem simplen Kopieren der Codezeilen), führen dazu, dass dezentrale Systeme bei einem Merge nicht nur auf den bloßen Inhalt von Dateien schauen müssen.

Um Merge-Konflikte zu minimieren, ist Vorbeugung das beste Mittel. Machen Sie kleine Commits! Fassen Sie Ihre Änderungen so zusammen, dass der resultierende Commit als Einheit Sinn ergibt. Bauen Sie Topic-Branches immer auf dem neuesten Release auf. Mergen Sie von Topic-Branches in „Sammel-Branches“ oder direkt in den master, nicht anders herum.^[45] Der Einsatz von Rerere erlaubt es, dass bereits gelöste Konflikte nicht ständig erneut auftreten.

Offensichtlich zählt zur Vorbeugung auch gute Kommunikation unter den Entwicklern: Wenn mehrere Entwickler an der gleichen Funktion unterschiedliche und sich gegenseitig beeinflussende Änderungen implementieren, wird das früher oder später sicher zu Konflikten führen.

Ein weiterer Faktor, der leider häufig zu unnötigen(!) Konflikten führt, sind autogenerierte Inhalte. Angenommen, Sie schreiben die Dokumentation einer Software in AsciiDoc⁠^[46] oder arbeiten an einem LaTeX-Projekt mit mehreren Mitstreitern: Fügen Sie keinesfalls die kompilierten Man-Pages oder das kompilierte DVI/PS/PDF im Repository ein! In den autogenerierten Formaten können kleine Änderungen am Plaintext (d.h. in der Ascii- bzw. LaTeX-Version) große (und unvorhersehbare) Änderungen an den kompilierten Formaten hervorrufen, die Git nicht adäquat auflösen wird. Sinnvoll ist es stattdessen, entsprechende Makefile-Targets oder Scripte bereitzustellen, um die Dateien zu generieren, und möglicherweise die kompilierte Version auf einem separaten Branch vorzuhalten.^[47]

Da die Auflistung mehrerer Commits kaum zu überblicken ist, untersuchen wir ein kleines Beispiel-Repository mit mehreren Branches, die untereinander gemergt wurden:

Abbildung 3.12. Der Graph der Commits, wie er in gitk dargestellt wird

Wir erkennen vier Branches (A-D) sowie einen Tag release. Diesen Baum können wir mit geeigneten Kommandozeilenoptionen auch per log-Kommando auf der Konsole anzeigen lassen (Branch- und Tag-Namen sind zur besseren Unterscheidung halbfett gedruckt):

$ git log --decorate --pretty=oneline --abbrev-commit --graph --all
* c937566 (HEAD, D) commit on branch D
| *   b0b30ef (release, A) Merge branch 'C' into A
| |\
| | * 807db47 (C) commit on branch C
| | * 996a53b commit on branch C
| |/
|/|
| * 83f6bf3 commit on branch A
| *   5b2c291 Merge branch 'B' into A
| |\
| | * 2417cf7 (B) commit on branch B
| |/
|/|
| * 0bf1433 commit on branch A
|/
* 4783886 initial commit

$ git config --global alias.tree 'log --decorate \
   --pretty=oneline --abbrev-commit --graph'

Nun verändern wir obiges Kommando: Statt der Option --all, die alle Commits im Baum unterbringt, geben wir nun B an (den Namen des Branch):

$ git tree B
* 2417cf7 (B) commit on branch B
* 4783886 initial commit

Wir erhalten alle Commits, die von B aus erreichbar sind. Ein Commit kennt jeweils nur seinen bzw. seine Vorgänger (mehrere dann, wenn Branches zusammengeführt werden). „Alle von B erreichbaren Commits“ bezeichnet also die Liste der Commits von B an weiter bis zu einem Commit, der keinen Vorgänger hat (genannt Root-Commit).

Statt einer kann das Kommando auch mehrere Referenzen entgegennehmen. Um also die gleiche Ausgabe wie mit der Option --all zu erhalten, müssen Sie die Referenzen A, B und D angeben. C kann ausgelassen werden, weil der Commit auf dem Weg von A zum Root-Commit bereits „eingesammelt“ wird.

Natürlich können Sie statt symbolischer Referenzen auch direkt eine SHA-1-Summe angeben:

$ git tree 5b2c291
*   5b2c291 Merge branch 'B' into A
|\
| * 2417cf7 (B) commit on branch B
* | 0bf1433 commit on branch A
|/
* 4783886 initial commit

Wird einer Referenz ein Caret (^) vorangestellt, so negiert das die Bedeutung.^[50] Die Notation ^A bedeutet also: nicht die Commits, die von A aus erreichbar sind. Allerdings schließt dieser Schalter lediglich diese Commits aus, nicht jedoch die anderen ein. Obiges log-Kommando mit dem Argument ^A wird also nichts ausgeben, da Git nur weiß, welche Commits nicht angezeigt werden sollen. Wir fügen also wieder --all hinzu, um alle Commits aufzulisten, abzüglich derer, die von A erreichbar sind:

$ git tree --all ^A
* c937566 (HEAD, D) commit on branch D

Eine alternative Notation ist mit --not verfügbar: Statt ^A kann man auch --not A schreiben.

Besonders hilfreich sind solche Kommandos, um den Unterschied zwischen zwei Branches zu untersuchen: Welche Commits sind in Branch D, die nicht in A sind? Die Antwort liefert das Kommando:

$ git tree D ^A
* c937566 (HEAD, D) commit on branch D

Weil sich diese Frage häufig stellt, gibt es dafür eine andere, intuitivere Notation: A..D ist gleichbedeutend mit D ^A:

$ git tree A..D
* c937566 (HEAD, D) commit on branch D

Natürlich ist hier die Reihenfolge wichtig: „D ohne A“ ist eine andere Menge von Commits als „A ohne D“! (Vergleiche auch den vollständigen Graphen.)

Im unserem Beispiel gibt es einen Tag release. Um zu überprüfen, welche Commits aus dem Branch D (der für „Development“ stehen könnte) noch nicht im aktuellen Release enthalten sind, genügt die Angabe release..D.

Gitk ist ein in Tcl implementiertes grafisches Programm, das in der Regel von Distributoren zusammen mit den eigentlichen Git-Kommandos paketiert wird – Sie können sich also darauf verlassen, es auf fast jedem System vorzufinden.

Es repräsentiert einzelne Commits oder das ganze Repository in einer dreiteiligen Ansicht: Oben die Baumstruktur mit zwei weiteren Spalten für Autor und Datum, unten eine Auflistung der Änderungen im Unified-Diff-Format sowie eine Liste von Dateien, um die angezeigten Änderungen einzuschränken.

Die Graph-Ansicht ist intuitiv: Verschiedene Farben helfen, die verschiedenen Versionsstränge zu unterscheiden. Commits sind jeweils blaue Punkte, mit zwei Ausnahmen: Der HEAD ist gelb markiert, und ein Commit, der nicht Root-Commit ist, dessen Vorgänger aber nicht angezeigt ist, wird weiß dargestellt.

Branches mit einer Pfeilspitze deuten an, dass auf dem Branch weitere Commits getätigt wurden. Aufgrund der zeitlichen Distanz der Commits blendet Gitk aber den Branch aus. Ein Klick auf die Pfeilspitze bringt Sie zu der Weiterführung des Branches.

Branches erscheinen als grüne Labels, der aktuell ausgecheckte Branch zusätzlich fett. Tags sind als gelbe Pfeile dargestellt.

Mit einem Rechtsklick auf einen Branch können Sie diesen löschen oder auschecken. Auf Commits öffnet ein Rechtsklick ein Menü, in dem Sie Aktionen mit dem markierten Commit ausführen können. Die einzige, die mit Gitk möglicherweise leichter zu bewerkstelligen ist als über die Kommandozeile, ist Cherry-Picking, also das Übernehmen einzelner Commits in einen anderen Branch (siehe auch Abschnitt 3.5, „Einzelne Commits übernehmen: Cherry-Pick“).

Abbildung 3.13. Komplizierte Topologie in Gitk

Gitk akzeptiert im wesentlichen die gleichen Optionen wie git log. Einige Beispiele:

$ gitk --since=yesterday -- doc/
$ gitk e13404a..48effd3
$ gitk --all -n 100

Das erste Kommando zeigt alle Commits seit gestern an, die Änderungen an einer Datei unterhalb des Verzeichnisses doc/ vorgenommen haben. Das zweite Kommando limitiert die Commits auf eine spezielle Range, während das dritte Kommando die 100 neuesten Commits aller Branches anzeigt.

Viele Nutzer lassen gitk während der Arbeit offen. Dann ist es wichtig, von Zeit zu Zeit die Anzeige zu aktualisieren, damit auch aktuellere Commits erscheinen. Mit F5 (Update) laden Sie alle neuen Commits und erneuern die Darstellung der Referenzen. Manchmal, wenn Sie z.B. einen Branch löschen, reicht dies jedoch nicht aus. Zwar wird der Branch nicht mehr angezeigt, aber evtl. sind unerreichbare Commits weiterhin quasi als Artefakte in der GUI vorhanden. Mit der Tastenkombination Strg+F5 (Reload) wird das Repository vollständig neu eingelesen, was das Problem beseitigt.

Alternativ zu gitk können Sie auf UNIX-Systemen das GTK-basierte gitg oder Qt-basierte qgit verwenden; auf einem OS-X-System können Sie beispielsweise GitX verwenden; für Windows bieten sich die GitExtensions an. Einige IDEs verfügen mittlerweile auch über entsprechende Visualisierungen (z.B. das Eclipse-Plugin EGit). Weiterhin können Sie vollwertige Git-Clients wie Atlassian SourceTree (OS X, Windows; kostenlos), Tower (OS X; kommerziell) sowie SmartGit (Linux, OS X und Windows; kostenlos für nichtkommerzielle Nutzung) verwenden.