Kapitel 4. Fortgeschrittene Konzepte

Betrachten Sie folgende Situation: Der Branch sqlite-support zweigt vom Commit „fixed a bug…“ ab. Der master-Branch ist aber schon weitergerückt, und ein neues Release 1.4.2 ist erschienen.

Abbildung 4.3. Vor dem Rebase

Nun wird sqlite-support ausgecheckt und neu auf master aufgebaut:

$ git checkout sqlite-support
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: include sqlite header files, prototypes
Applying: generalize queries
Applying: modify Makefile to support sqlite

Rebase wendet die drei Änderungen, die durch Commits aus dem Branch sqlite-support eingeführt werden, auf den master-Branch an. Danach sieht das Repository in Gitk wie folgt aus:

Abbildung 4.4. Nach Rebase

Normalerweise wird git rebase immer den Branch, auf dem Sie gerade arbeiten, auf einen neuen aufbauen. Allerdings gibt es eine Abkürzung: Wollen Sie topic auf master aufbauen, befinden sich aber auf einem ganz anderen Branch, können Sie das per

$ git rebase master topic

Git macht intern Folgendes:

$ git checkout topic
$ git rebase master

Beachten Sie die (leider wenig intuitive) Reihenfolge:

git rebase <worauf> <was>

Bei einem Rebase kann es zu Konflikten kommen. Der Prozess hält dann mit folgender Fehlermeldung an:

$ git rebase master
...
CONFLICT (content): Merge conflict in <datei>
Failed to merge in the changes.
Patch failed at ...
The copy of the patch that failed is found in:
   .../.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase
--abort".

Sie gehen vor wie bei einem regulären Merge-Konflikt (siehe Abschnitt 3.4, „Merge-Konflikte lösen“) – git mergetool ist hier sehr hilfreich. Fügen Sie dann einfach die geänderte Datei per git add hinzu und lassen Sie den Prozess per git rebase --continue weiterlaufen.^[54]

Alternativ lässt sich der problematische Commit auch überspringen, und zwar mit dem Kommando git rebase --skip. Der Commit ist dann aber verloren, sofern er nicht in einem anderen Branch irgendwo referenziert wird! Sie sollten diese Aktion also nur ausführen, wenn Sie sicher wissen, dass der Commit obsolet ist.

Wenn das alles nicht weiterhilft (Sie z.B. den Konflikt nicht an der Stelle lösen können oder gemerkt haben, dass Sie gerade den falschen Baum umbauen), ziehen Sie die Notbremse: git rebase --abort. Dies verwirft alle Änderungen am Repository (auch schon erfolgreich kopierte Commits), so dass der Zustand danach genau so ist, wie zu dem Zeitpunkt, als der Rebase-Prozess gestartet wurde. Das Kommando hilft auch, wenn Sie irgendwann vergessen haben, einen Rebase-Prozess zu Ende zu führen, und sich andere Kommandos beschweren, dass sie ihre Arbeit nicht verrichten können, weil gerade ein Rebase im Gang ist.

Rebase ist vor allem sinnvoll, um die Commit-Geschichte eines Projekts einfach und leicht verständlich zu halten. Beispielsweise arbeitet ein Entwickler an einem Feature, hat dann aber ein paar Wochen lang etwas anderes zu tun. Währenddessen ist die Entwicklung im Projekt aber schon weiter vorangeschritten, es gab ein neues Release etc. Erst jetzt kommt der Entwickler dazu, ein Feature zu beenden. (Auch wenn Sie Patches per E-Mail verschicken wollen, hilft Rebase, Konflikte zu vermeiden, siehe dazu Abschnitt 5.9, „Patches per E-Mail“.)

Für die Versionsgeschichte ist es nun viel logischer, wenn sein Feature nicht über einen langen Zeitraum unfertig neben der eigentlichen Entwicklung „mitgeschleppt“ wurde, sondern wenn die Entwicklung vom letzten stabilen Release abzweigt.

Für genau diese Änderung in der Geschichte ist Rebase gut: Der Entwickler kann nun einfach auf seinem Branch, auf dem er das Feature entwickelt hat, das Kommando git rebase v1.4.2 eingeben, um seinen Feature-Branch neu auf dem Commit mit dem Release-Tag v1.4.2 aufzubauen. So lässt sich wesentlich leichter ablesen, welche Unterschiede das Feature wirklich in die Software einbringt.

Auch passiert es jedem Entwickler im Eifer des Gefechts, dass Commits im falschen Branch landen. Da findet sich zufällig ein Fehler, der schnell durch einen entsprechenden Commit behoben wird; aber dann muss direkt noch ein Test geschrieben werden, um diesen Fehler in Zukunft zu vermeiden (ein weiterer Commit), was wiederum in der Dokumentation entsprechend zu vermerken ist. Nachdem die eigentliche Arbeit getan ist, kann man diese Commits mit Rebase an eine andere Stelle im Commit-Graphen „transplantieren“.

Rebase kann auch dann sinnvoll sein, wenn in einem Branch ein Feature benötigt wird, das erst kürzlich in die Software eingeflossen ist. Ein Merge des master-Branches ist semantisch nicht sinnvoll, da dann diese und andere Änderungen untrennbar mit dem Feature-Branch verschmolzen werden. Stattdessen baut man den Branch per Rebase auf einen neuen Commit auf, in dem das benötigte Feature schon enthalten ist, und kann dieses dann in der weiteren Entwicklung nutzen.

Das Konzept von Rebase ist zunächst etwas schwierig zu verstehen. Aber sobald Sie verstanden haben, was damit möglich ist, stellt sich die Frage: Wozu braucht man überhaupt noch ein simples Merge, wenn man doch alles mit Rebase bearbeiten kann?

Wenn Git-Rebase nicht oder kaum angewendet wird, entwickelt sich häufig eine Projektgeschichte, die relativ unüberschaubar wird, weil ständig und jeweils für wenige Commits Merges ausgeführt werden müssen.

Wird Rebase dagegen zu viel angewendet, besteht die Gefahr, dass das gesamte Projekt sinnlos linearisiert wird: Das flexible Branching von Git wird zwar zur Entwicklung genutzt, die Branches werden aber dann reißverschlussartig per Rebase hintereinander(!) in den Veröffentlichungsbranch integriert. Das stellt uns vor allem vor zwei Probleme:

So verspielen Sie die Vorteile des flexiblen Branchings von Git. Die Schlussfolgerung ist, dass Rebase weder zu viel noch zu wenig angewendet werden sollte. Beides macht die Projektgeschichte (auf unterschiedliche Art und Weise) unübersichtlich.

Generell fahren Sie mit den folgenden Faustregeln gut:

Wie schon angesprochen, ändern sich bei einem Rebase zwangsläufig die SHA-1-Summen aller Commits, die „umgebaut“ werden. Wenn diese Änderungen noch nicht veröffentlicht wurden, d.h. bei einem Entwickler im privaten Repository liegen, ist das auch nicht schlimm.

Wenn aber ein Branch (z.B. master) veröffentlicht^[55] und später per Rebase umgeschrieben wird, hat das unschöne Folgen für alle Beteiligten: Alle Branches, die auf master aufbauen, referenzieren nun die alte Kopie des mittlerweile umgeschriebenen master-Branches. Also muss jeder Branch wiederum per Rebase auf den neuen master aufgebaut werden (wodurch sich wiederum alle Commit-IDs ändern). Dieser Effekt setzt sich fort und kann (je nachdem, wann so ein Rebase passiert und wie viele Entwickler an dem Projekt beteiligt sind) sehr zeitaufwendig zu beheben sein (das trifft vor allem dann zu, wenn Git-Neulinge dabei sind).

Daher sollten Sie immer an folgende Regel denken:

Ausnahmen bilden Konventionen wie persönliche Branches oder pu. Letzterer ist ein Kürzel für Proposed Updates und ist in der Regel ein Branch, in dem neue, experimentelle Features auf Kompatibilität getestet werden. Auf diesen Branch baut sinnvollerweise niemand seine eigene Arbeit auf, daher kann er ohne Probleme und vorherige Ankündigung umgeschrieben werden.

Eine weitere Möglichkeit bieten private Branches, also solche, die zum Beispiel mit <user>/ starten. Trifft man die Vereinbarung, dass Entwickler auf diesen Branches eigene Entwicklung betreiben, aber ihre Features immer nur auf „offiziellen“ Branches aufbauen, dann dürfen die Entwickler ihre Branches beliebig umschreiben.

Wird über einen langen Zeitraum an einem Feature entwickelt, und Teile des Features fließen schon in ein Mainstream-Release (z.B. per cherry-pick), dann erkennt das Rebase-Kommando diese Commits und lässt sie beim Kopieren bzw. Neuaufbauen der Commits aus, da die Änderung schon in dem Branch enthalten ist.

So besteht der neue Branch nach einem Rebase nur aus den Commits, die noch nicht in den Basis-Branch eingeflossen sind. Auf diese Weise treten Commits nicht doppelt in der Versionsgeschichte eines Projekts auf. Wäre der Branch einfach nur per Merge integriert worden, so wären mitunter die gleichen Commits mit unterschiedlichen SHA-1-Summen an verschiedenen Stellen im Commit-Graphen vorhanden.

Es gibt Situationen, in denen es von einer Software eine Vanilla-Version („einfachste Version“) gibt und außerdem eine gewisse Anzahl von Patches, die darauf angewendet werden, bevor die Vanilla-Version ausgeliefert wird. Zum Beispiel baut Ihre Firma eine Software, aber vor jeder Auslieferung an den Kunden müssen (je nach Kunde) einige Anpassungen vorgenommen werden. Oder Sie haben eine Open-Source-Software im Einsatz, diese aber ein wenig an Ihre Bedürfnisse angepasst – jedes Mal, wenn nun eine neue, offizielle Version der Software erscheint, müssen Sie Ihre Änderungen neu anwenden und die Software anschließend neu bauen.^[56]

Um Patch-Stacks zu verwalten, gibt es einige Programme, die auf Git aufbauen, Ihnen aber den Komfort bieten, nicht direkt mit dem Rebase-Kommando arbeiten zu müssen. Beispielsweise erlaubt TopGit^[57] Ihnen, Abhängigkeiten zwischen Branches zu definieren – wenn sich dann in einem Branch etwas ändert und andere Branches hängen davon ab, baut TopGit diese auf Wunsch neu auf. Eine Alternative zu TopGit ist Stacked Git^[58].

Sie mögen sich nun gewundert haben: git rebase <referenz> kopiert immer alle Commits, die zwischen <referenz> und HEAD liegen. Was aber, wenn Sie nur einen Teil eines Branches umsetzen, quasi „transplantieren“ möchten? Betrachten Sie folgende Situation:

Abbildung 4.5. Vor dem rebase --onto

Sie haben gerade auf dem Branch topic ein Feature entwickelt, als Ihnen ein Fehler aufgefallen ist; Sie haben einen Branch bugfix erstellt und noch einen Fehler gefunden. Rein semantisch hat aber Ihr Branch bugfix nichts mit dem topic-Branch zu tun. Sinnvollerweise sollte er daher vom master-Branch abzweigen.

Wenn Sie nun aber per git rebase master den Branch bugfix neu aufbauen, passiert Folgendes: Alle Knoten, die in bugfix enthalten sind, aber nicht im master, werden der Reihe nach auf den master-Branch kopiert – das sind also die Knoten D, E, F und G. Dabei gehören jedoch D und E gar nicht zum Bugfix.

Hier kommt nun die Option --onto ins Spiel: Sie erlaubt, einen Start- und Endpunkt für die Liste der zu kopierenden Commits anzugeben. Die allgemeine Syntax lautet:

git rebase --onto <worauf> <start> <ziel>

In diesem Beispiel wollen wir nur die Commits F und G (oder auch: die Commits von topic bis bugfix) von oben auf master aufbauen. Daher lautet das Kommando:

$ git rebase --onto master topic bugfix

Das Ergebnis sieht aus wie erwartet:

Abbildung 4.6. Nach einem rebase --onto

Sie haben in Abschnitt 2.1, „Git-Kommandos“ das Kommando commit --amend kennengelernt, mit dem Sie einen Commit verbessern. Es bezieht sich aber immer nur auf den aktuellen (letzten) Commit. Mit rebase --onto können Sie auch Commits anpassen, die weiter in der Vergangenheit liegen.

Suchen Sie zunächst den Commit heraus, den Sie editieren wollen, und erstellen Sie einen Branch darauf:

$ git checkout -b fix-master 21d8691

Anschließend führen Sie Ihre Änderungen aus, fügen geänderte Dateien mit git add hinzu und korrigieren dann den Commit mit git commit --amend --no-edit (die Option --no-edit übernimmt Meta-Informationen wie die Beschreibung des alten Commits und bietet diese nicht erneut zum Editieren an).

Nun spielen Sie alle Commits aus dem master-Branch von oben auf Ihren korrigierten Commit auf:

$ git rebase --onto fix-master 21d8691 master

Sie kopieren so alle Commits von 21d8691 (exklusive!) bis master (inklusive!). Der fehlerhafte Commit 21d8691 wird nicht mehr referenziert und taucht daher nicht mehr auf. Der Branch fix-master ist nun obsolet und kann gelöscht werden.

Eine äquivalente Möglichkeit, einen Commit zu editieren, haben Sie mit der Aktion edit im interaktiven Rebase (siehe Abschnitt 4.2.2, „Commits beliebig editieren“).

Es gibt Situationen, in denen Sie das Standardverhalten von git rebase anpassen müssen. Erstens ist dies der Fall, wenn Sie einen Branch mit Rebase bearbeiten, der Merges enthält. Rebase kann versuchen, diese nachzuahmen statt die Commits zu linearisieren. Zuständig ist die Option -p bzw. --preserve-merges.^[59]

Mit der Option -m bzw. --merge können Sie git rebase anweisen, Merge-Strategien zu verwenden (siehe dafür auch Abschnitt 3.3.3, „Merge-Strategien“). Wenn Sie diese Strategien anwenden, bedenken Sie, dass Rebase intern Commit für Commit per cherry-pick auf den neuen Branch aufspielt; daher sind die Rollen von ours und theirs vertauscht: theirs bezeichnet den Branch, den Sie auf eine neue Basis aufbauen!

Ein interessanter Anwendungsfall ist daher die Strategie-Option theirs für die Merge-Strategie recursive: Falls Konflikte auftreten, wird den Änderungen aus dem Commit, der kopiert wird, Vorrang gegeben. Ein solches Szenario ist also sinnvoll, wenn Sie wissen, dass es konfliktverursachende Änderungen gibt, sich aber sicher sind, dass die Änderungen des neu aufzubauenden Branches „richtiger“ sind als die des Baumes, auf den Sie aufbauen. Wenn Sie topic neu auf master aufbauen, sähe ein solcher Aufruf so aus:

$ git checkout topic
$ git rebase -m -Xtheirs master

In den Fällen, in denen die recursive-Strategie (Default) den Änderungen aus Commits aus topic den Vorzug gibt, werden Sie einen entsprechenden Hinweis Auto-merging <Commit-Beschreibung> finden.

Eine kleine, sehr nützliche Option, die von Rebase direkt an git apply weitergeleitet wird, ist --whitespace=fix. Sie veranlasst Git, automatisch Whitespace-Fehler (z.B. Trailing-Spaces) zu korrigieren. Falls Sie Merge-Konflikte aufgrund von Whitespace haben (zum Beispiel wegen geänderter Einrückung), können Sie auch die in Abschnitt 3.3.4, „Optionen für die recursive-Strategie“ vorgestellten Strategie-Optionen verwenden, um automatisch Lösungen erzeugen zu lassen (zum Beispiel durch Angabe von -Xignore-space-change).

Die Kommandos squash bzw. fixup erlauben es, zwei oder mehr Commits miteinander zu verschmelzen.

Niemand schreibt immer sofort fehlerfreien Code. Häufig gibt es einen großen Commit, in dem Sie ein neues Feature implementiert haben; kurz darauf finden sich kleine Fehler. Was tun? Eine ausführliche Beschreibung, warum Sie aus Unachtsamkeit vergessen haben, eine Zeile hinzuzufügen oder zu entfernen? Nicht wirklich sinnvoll, und vor allem störend für andere Entwickler, die später Ihren Code überprüfen wollen. Schöner wäre es doch, die Illusion zu wahren, dass der Commit gleich beim ersten Mal fehlerfrei war…

Für jeden Fehler, den Sie finden, machen Sie einen kleinen Commit mit einer mehr oder weniger sinnvollen Beschreibung. Das könnte dann zum Beispiel so aussehen:

$ git log --oneline master..feature
b5ffeb7 fix feature 1
34c4453 fix feature 2
ac445c6 fix feature 1
ae65efd implement feature 2
cf30f4d implement feature 1

Wenn sich einige solche Commits angesammelt haben, starten Sie einen interaktiven Rebase-Prozess über die letzten Commits. Schätzen Sie dazu einfach ab, auf wie vielen Commits Sie arbeiten wollen, und bearbeiten Sie dann beispielsweise per git rebase -i HEAD~5 die letzten fünf.

Im Editor erscheinen die Commits nun in umgekehrter Reihenfolge im Vergleich zur Ausgabe von git log. Ordnen Sie nun die kleinen Bugfix-Commits so an, dass sie unter dem Commit, den sie korrigieren, stehen. Markieren Sie dann die Korrektur-Commits mit squash (oder s), also z.B. so:

pick cf30f4d implement feature 1
s ac445c6 fix feature 1
s b5ffeb7 fix feature 1
pick ae65efd implement feature 2
s 34c4453 fix feature 2

Speichern Sie die Datei und beenden Sie den Editor; der Rebase-Prozess startet. Weil Sie squash ausgewählt haben, hält Rebase an, nachdem Commits verschmolzen wurden. Im Editor erscheinen die Commit-Nachrichten der verschmolzenen Commits, die Sie nun geeignet zusammenfassen. Verwenden Sie statt squash das Schlüsselwort fixup oder kurz f, wird die Commit-Nachricht der so markierten Commits weggeworfen – für diese Arbeitsweise also vermutlich praktischer.

Nach dem Rebase sieht die Versionsgeschichte viel aufgeräumter aus:

$ git log --oneline master..feature
97fe253 implement feature 2
6329a8a implement feature 1

$ git config --global alias.fixup "commit --amend --no-edit"

Wenn Sie die Commit-Nachricht mit fixup! bzw. squash! beginnen, gefolgt vom Anfang der Beschreibung des Commits, den Sie korrigieren wollen, können Sie das Kommando

$ git rebase -i --autosquash master

aufrufen. Die wie oben mit fixup! bzw. squash! markierten Commits werden automatisch an die richtige Stelle verschoben und mit der Aktion squash bzw. fixup versehen. So können Sie den Editor direkt beenden, und die Commits werden verschmolzen. Falls Sie häufig mit dieser Option arbeiten, können Sie dieses Verhalten auch durch eine Konfigurationsoption zum Standard bei Rebase-Aufrufen machen: Setzen Sie dafür die Einstellung rebase.autosquash auf true.

Wenn Sie einen Commit mit edit markieren, kann er beliebig editiert werden. Dabei geht Rebase wie in den anderen Fällen auch sequentiell die Commits durch. Bei den Commits, die mit edit markiert sind, hält Rebase an und HEAD wird auf den entsprechenden Commit gesetzt. Sie können dann den Commit ändern, als wäre er der aktuellste im Branch. Anschließend lassen Sie Rebase weiterlaufen:

$ vim ...
# Korrekturen vornehmen
$ git add ...
$ git commit --amend
$ git rebase --continue

Im Wesentlichen erreichen Sie dabei dasselbe wie im Beispiel git rebase --onto in Abschnitt 4.1.9, „Einen Commit verbessern“ – allerdings können Sie auch weit kompliziertere Aktionen ausführen. Einen häufigen Anwendungsfall beschreibt folgendes „Rezept“.

$ git reset HEAD^

$ git add -p
$ git commit -m "Erster Teil"
$ git add -p
$ git commit -m "Zweiter Teil"
$ git add -u
$ git commit -m "Dritter (und letzter) Teil";

Eine bequeme Alternative zu git blame auf der Konsole bietet das grafische Tool git gui blame (hierfür müssen Sie gegebenenfalls das Paket git-gui installieren).

Abbildung 4.7. Ein Stück Code, das aus einer anderen Datei verschoben wurde

Wenn Sie eine Datei per git gui blame <datei> untersuchen, werden die unterschiedlichen Blöcke, die aus verschiedenen Commits stammen, mit Grautönen hinterlegt dargestellt. Links sehen Sie die abgekürzte Commit-ID sowie die Initialen des Autors.

Erst wenn Sie mit der Maus über einen solchen Block fahren, erscheint ein kleines Popup-Fenster mit Informationen zum Commit, der die Zeilen geändert hat, möglicherweise auch mit einer Mitteilung, aus welcher Datei und welchem Commit dieser Codeblock verschoben oder kopiert wurde.

Bei der Code-Review interessiert man sich häufig dafür, wie eine Datei eigentlich vor einer bestimmten Änderung aussah. Dafür bietet das grafische Blame-Tool die folgende Möglichkeit, in der Versionsgeschichte zurückzugehen: Klicken Sie mit der rechten Maustaste auf die Commit-ID eines Code-Blocks und wählen Sie im Kontextmenü Blame Parent Commit aus – nun wird der Vorgänger dieser Änderung angezeigt. Sie können auf diese Weise mehrere Schritte zurückgehen. Über den grünen Pfeil links oben können Sie wieder in die Zukunft springen.

Die Syntax für Muster ist der Shell-Syntax nachempfunden:

Ein Beispiel:^[60]

$ cat ~/.gitignore
# vim swap files
.*.sw[nop]

# python bytecode
*.pyc

# documents
*.dvi
*.pdf

# miscellaneous
*.*~
*.out

Dateien, die bereits versioniert sind, werden nicht automatisch ignoriert. Um eine solche Datei trotzdem zu ignorieren, weisen Sie Git explizit an, die Datei zu „vergessen“:

$ git rm documentation.pdf

Um die Datei mit dem nächsten Commit zu löschen, aber trotzdem im Working Tree vorzuhalten:

$ git rm --cached documentation.pdf

Dateien, die bereits ignoriert werden, erscheinen in der Ausgabe von git status nicht. Außerdem weigert sich git add, die Datei zu übernehmen; mit der Option --force bzw. -f zwingen Sie Git, die Datei doch zu beachten:

$ git add documentation.pdf
The following paths are ignored by one of your .gitignore files:
documentation.pdf
Use -f if you really want to add them.
fatal: no files added
$ git add -f documentation.pdf

Das Kommando git clean löscht ignorierte sowie unbekannte (sog. untracked) Dateien. Da evtl. Dateien unwiederbringlich verlorengehen könnten, verfügt das Kommando über die Option --dry-run (bzw. -n); sie gibt Auskunft, was gelöscht würde. Als weitere Vorsichtsmaßnahme weigert sich das Kommando, irgendetwas zu löschen, außer Sie übergeben explizit die Option --force bzw. -f.^[61]

Standardmäßig löscht git clean nur die unbekannten Dateien, mit -X entfernt es nur die ignorierten Dateien und mit -x sowohl unbekannte als auch ignorierte. Mit der Option -d werden zusätzlich Verzeichnisse gelöscht, die in Frage kommen. Um also unbekannte sowie ignorierte Dateien und Verzeichnisse zu löschen, geben Sie ein:

$ git clean -dfx

Mit git stash speichern Sie den aktuellen Zustand von Working Tree und Index, sofern diese sich von HEAD unterscheiden:

$ git stash
Saved working directory and index state WIP on master: b529e34 new spec
 how the script should behave
HEAD is now at b529e34 new spec how the script should behave

Mit der Option --keep-index bleibt der Index intakt. Das heißt, alle Veränderungen die bereits im Index sind, bleiben im Working Tree und im Index vorhanden und werden zusätzlich im Stash gespeichert.

Die Veränderungen am Working Tree sowie dem Index werden „beiseite geschafft“, und Git erzeugt keinen Commit auf dem aktuellen Branch. Um den gespeicherten Zustand wieder herzustellen, also um den gespeicherten Patch auf dem aktuellen Working Tree anzuwenden und gleichzeitig den Stash zu löschen, verwenden Sie:

$ git stash pop
...
Dropped refs/stash@{0} (d4cc94c37e92390e5fabf184a3b5b7ebd5c3943a)

Sie können zwischen dem Abspeichern und dem Wiederherstellen das Repository beliebig verändern, z.B. den Branch wechseln, Commits machen usw. Der Stash wird immer auf den aktuellen Working Tree angewendet.

Das Kommando git stash pop ist eine Abkürzung für die zwei Kommandos git stash apply (Stash anwenden) und git stash drop (Stash verwerfen):

$ git stash apply
...
$ git stash drop
Dropped refs/stash@{0} (d4cc94c37e92390e5fabf184a3b5b7ebd5c3943a)

Sowohl pop als auch apply pflegen die Veränderungen in den Working Tree ein, der Zustand des Index wird nicht wieder hergestellt. Mit der Option --index stellen Sie auch den abgespeicherten Zustand des Index wieder her.

$ git stash -p

Es kann zu Konflikten kommen, wenn Sie einen Stash auf einem anderen Commit anwenden als dem, auf dem er entstanden ist:

$ git stash pop
Auto-merging hello.pl
CONFLICT (content): Merge conflict in hello.pl

In dem Fall verwenden Sie die üblichen Rezepte zum Lösen des Konflikts, siehe Abschnitt 3.4, „Merge-Konflikte lösen“. Wichtig ist aber, dass die Konflikt-Marker die Bezeichnungen Updated Upstream (die Version im aktuellen Working Tree) sowie Stashed Changes (Veränderungen im Stash) tragen:

<<<<<<< Updated upstream
# E-Mail: valentin.haenel@gmx.de
========
# E-Mail: valentin@gitbu.ch
>>>>>>> Stashed changes

Der Stash wird per Default auf den aktuellen Working Tree angewendet, vorausgesetzt dieser ist sauber – wenn nicht, bricht Git ab:

$ git stash pop
Cannot apply to a dirty working tree, please stage your changes

Git schlägt zwar vor, dass Sie die Änderungen dem Index hinzufügen, wie Sie aber vorgehen sollten, hängt von Ihrem Ziel ab. Wenn Sie die Änderungen im Stash zusätzlich zu denen im Working Tree haben wollen, bietet sich Folgendes an:

$ git add -u
$ git stash pop
$ git reset HEAD

Zur Erläuterung: Zuerst werden die noch nicht gespeicherten Veränderungen am Working Tree dem Index hinzugefügt; dann die Veränderungen aus dem Stash herausgeholt und auf den Working Tree angewendet, und zuletzt noch der Index zurückgesetzt.

Alternativ dazu können Sie auch einen zusätzlichen Stash erstellen, und die Veränderungen, die Sie haben wollen, auf einen sauberen Working Tree anwenden:

$ git stash
$ git stash apply stash@{1}
$ git stash drop stash@{1}

Bei diesem Rezept verwenden Sie mehrere Stashes. Zuerst lagern Sie die Veränderungen am Working Tree in einen neuen Stash aus, dann holen Sie die Veränderungen, die Sie eigentlich haben wollen, aus dem vorherigen Stash und löschen diesen nach der Anwendung.

Standardmäßig setzt Git für einen Stash die folgende Nachricht:

WIP: on <branch>: <sha1> <commit-msg>

Meist reicht dies aus, um einen Stash zu identifizieren. Wenn Sie vorhaben, Ihre Stashes länger vorzuhalten (möglich, aber nicht wirklich zu empfehlen), oder wenn Sie mehrere machen wollen, raten wir, diese mit einer besseren Anmerkung zu versehen:

$ git stash save "unfertiges feature"
Saved working directory and index state On master: unfertiges feature
HEAD is now at b529e34 new spec how the script should behave

Git verwaltet alle Stashes als Stack, d.h. aktuellere Zustände liegen oben auf und werden zuerst verarbeitet. Die Stashes sind mit einer Reflog-Syntax (siehe auch Abschnitt 3.7, „Reflog“) benannt:

    stash@{0}
    stash@{1}
    stash@{2}
    ...

Erzeugen Sie einen neuen Stash, wird dieser als stash@{0} bezeichnet und die Nummer der anderen wird inkrementiert: Aus stash@{0} wird stash@{1}, aus stash@{1} wird stash@{2} usw.

Geben Sie keinen expliziten Stash an, beziehen sich die Kommandos apply, drop und show auf den neuesten, also stash@{0}.

Um einzelne Stashes einzusehen, verwenden Sie git stash show. Standardmäßig druckt dieses Kommando eine Bilanz der hinzugefügten und entfernten Zeilen aus (wie git diff --stat):

$ git stash show
git-stats.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

$ git stash show -p stash@{0}
diff --git a/git-stats.sh b/git-stats.sh
index 62f92fe..1235fd3 100755
--- a/git-stats.sh
+++ b/git-stats.sh
@@ -1,6 +1,6 @@
 #!/bin/bash
-START=18.07.2010
-END=25.07.2010
+START=18.07.2000
+END=25.07.2020
  echo "Number of commits per author:"

Das Kommando git stash list gibt eine Liste der derzeit angelegten Stashes aus:

$ git stash list
stash@{0}: WIP on master: eae23b6 add number of merge commits to output
stash@{1}: WIP on master: b1ee2cf start and end date in one place only

Einzelne Stashes löschen Sie mit dem Kommando git stash drop, alle mit git stash clear. Sollten Sie versehentlich einen Stash löschen, finden Sie diesen nicht über die üblichen Reflog-Mechanismen wieder! Jedoch gibt folgender Befehl die ehemaligen Stashes aus:^[62]

$ git fsck --unreachable | grep commit | cut -d" "  -f3 | \
  xargs git log --merges --no-walk --grep=WIP

Außerdem ist wichtig, dass die so gezeigten Einträge nur als unerreichbare Objekte in der Objektdatenbank vorhanden sind und somit auch den normalen Wartungsmechanismen unterliegen – sie werden also nach einiger Zeit gelöscht und nicht dauerhaft vorgehalten.

Git erzeugt für jeden Stash zwei Commit-Objekte, eines für die Veränderungen am Working Tree und eines für die Veränderungen am Index. Beide haben den aktuellen HEAD als Vorfahren, das Working-Tree-Objekt hat das Index-Objekt als Vorfahren. Dadurch wird ein Stash in Gitk als Dreieck angezeigt, was im ersten Moment etwas verwirrend ist:

Abbildung 4.8. Ein Stash in Gitk

Mit dem Alias git tree (siehe Abschnitt 3.6.1, „Revision Parameters“) sieht das so aus:

*   f1fda63 (refs/stash) WIP on master: e2c67eb Kommentar fehlte
|\
| * 4faee09 index on master: e2c67eb Kommentar fehlte
|/
* e2c67eb (HEAD, master) Kommentar fehlte
* 8e2f5f9 Test Datei
* 308aea1 README Datei
* b0400b0 Erste Version

Da die Stash-Objekte nicht durch einen Branch referenziert sind, wird das Working-Tree-Objekt mit einer besonderen Referenz, refs/stash, am Leben erhalten. Dies gilt aber nur für den neuesten Stash. Ältere Stashes werden nur im Reflog (siehe Abschnitt 3.7, „Reflog“) referenziert und erscheinen deshalb auch nicht in Gitk. Im Gegensatz zu normalen Reflog-Einträgen verfallen gespeicherte Stashes jedoch nicht und werden deshalb auch nicht durch die normalen Wartungsmechanismen gelöscht.

Eine bisect-Sitzung starten Sie mit den folgenden Kommandos:

$ git bisect start
$ git bisect bad <funktioniert-nicht>
$ git bisect good <funktioniert>

Sobald Sie die beiden Punkte definiert haben, checkt Git einen Commit in der Mitte aus, Sie befinden sich also ab jetzt im Detached-Head-Modus (siehe Abschnitt 3.2.1, „Detached HEAD“). Nachdem Sie überprüft haben, ob die Regression noch immer vorhanden ist, können Sie ihn mit git bisect good bzw. git bisect bad markieren. Git checkt automatisch den nächsten Commit aus.

Möglicherweise können Sie den ausgecheckten Commit nicht testen, z.B. weil das Programm nicht fehlerfrei kompiliert. In diesem Fall können Sie per Git git bisect skip einen anderen Commit in der Nähe auswählen lassen und mit diesem wie gewohnt verfahren. Die Fehlersuche können Sie jederzeit abbrechen per git bisect reset.

Idealerweise können Sie automatisiert testen, ob der Fehler auftritt – mit einem Test, der erfolgreich laufen muss, wenn die Regression nicht auftritt.

Sie können dann wie oben die Punkte good und bad definieren. Danach geben Sie git bisect run <pfad/zum/test> ein.

Anhand des Rückgabewerts entscheidet bisect, ob der überprüfte Commit good ist (wenn das Script sich erfolgreich, d.h. mit Rückgabewert 0 beendet) oder bad (Werte 1—127). Ein Spezialfall ist der Rückgabewert 125, der ein git bisect skip bewirkt. Wenn Sie also ein Programm haben, das kompiliert werden muss, sollten Sie als erstes ein Kommando wie make || exit 125 einbauen, so dass der Commit übersprungen wird, wenn das Programm nicht richtig kompiliert.

Bisect kann dann ganz automatisch den problematischen Commit identifizieren. Das sieht z.B. so aus:

$ git bisect run ./t.sh
Bisecting: 9 revisions left to test after this (roughly 3 steps) ...
Bisecting: 4 revisions left to test after this (roughly 2 steps) ...
Bisecting: 2 revisions left to test after this (roughly 1 step) ...
Bisecting: 0 revisions left to test after this (roughly 0 steps) ...
d29758fffc080d0d0a8ee9e5266fdf75fcb98076 is the first bad commit