fix missing diagrams in PDF output

Author: max123kl

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -165,7 +165,7 @@ Da der Commit auf dem Branch, auf dem Sie sich gerade befinden, kein unmittelbar
 In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die die Branch-Spitzen und der gemeinsame Vorfahr der beiden zeigen.
 
 .Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden
-image::images/basic-merging-1.png[Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden]
+image::images/basic-merging-1.png["Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden"]
 
 Anstatt einfach den Zeiger des Branches vorwärts zu bewegen, erstellt Git einen neuen Schnappschuss, der aus dem Drei-Wege-Merge resultiert und erzeugt automatisch einen neuen Commit, der darauf zeigt.
 Das wird auch als Merge-Commit bezeichnet und ist ein Spezialfall, weil er mehr als nur einen Vorgänger hat.

book/03-git-branching/sections/nutshell.asc

@@ -62,7 +62,7 @@ $ git branch testing
 Dieser Befehl erzeugt einen neuen Zeiger, der auf den selben Commit zeigt, auf dem Sie sich gegenwärtig befinden.
 
 .Zwei Branches, die auf dieselbe Serie von Commits zeigen
-image::images/two-branches.png[Zwei Branches, die auf dieselbe Serie von Commits zeigen]
+image::images/two-branches.png["Zwei Branches, die auf dieselbe Serie von Commits zeigen"]
 
 Woher weiß Git, auf welchem Branch Sie gegenwärtig sind?
 Es besitzt einen speziellen Zeiger namens `HEAD`.
@@ -114,7 +114,7 @@ $ git commit -a -m 'made a change'
 ----
 
 .Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird
-image::images/advance-testing.png[Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird]
+image::images/advance-testing.png["Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird"]
 
 Das ist interessant, weil sich jetzt Ihr `testing`-Branch vorwärts bewegt hat, aber Ihr `master`-Branch noch auf den Commit zeigt, auf dem Sie sich befanden, als Sie die Anweisung `git checkout` ausführten, um die Branches zu wechseln.
 Lassen Sie uns zurückwechseln zum `master`-Branch.
@@ -137,7 +137,7 @@ Um alle Branches zu sehen, fügen Sie `--all` zu Ihrem `git log` Kommando hinzu.
 ====
 
 .HEAD bewegt sich, wenn Sie auschecken
-image::images/checkout-master.png[HEAD bewegt sich, wenn Sie auschecken]
+image::images/checkout-master.png["HEAD bewegt sich, wenn Sie auschecken"]
 
 Diese Anweisung hat zwei Dinge bewirkt.
 Es bewegte den HEAD-Zeiger zurück, um auf den Branch `master` zu zeigen, und es setzte die Dateien in Ihrem Arbeitsverzeichnis zurück auf den Snapshot, auf den `master` zeigt.

book/03-git-branching/sections/rebasing.asc

@@ -164,7 +164,7 @@ Sie holen das Ganze dann von diesem Server ab und laden die neuen Commits herunt
 
 [[_pre_merge_rebase_work]]
 .Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen Ihre Arbeit basiert
-image::images/perils-of-rebasing-3.png[Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen Ihre Arbeit basiert]
+image::images/perils-of-rebasing-3.png["Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen Ihre Arbeit basiert"]
 
 Jetzt sitzen Sie beide in der Klemme.
 Wenn Sie ein `git pull` durchführen, würden Sie einen Merge-Commit erzeugen, welcher beide Entwicklungslinien einschließt, und Ihr Repository würde so aussehen:

book/06-github/sections/2-contributing.asc

@@ -54,7 +54,7 @@ Schauen wir uns ein Beispiel an, wie man mit diesem Workflow eine Anpassung an e
 Tony ist auf der Suche nach Code, der auf seinem programmierbaren Arduino-Mikrocontroller läuft und hat auf GitHub unter https://github.com/schacon/blink eine tolle Programmdatei gefunden.
 
 .Das Projekt, zu dem wir beitragen wollen
-image::images/blink-01-start.png[Das Projekt, zu dem wir beitragen wollen]
+image::images/blink-01-start.png["Das Projekt, zu dem wir beitragen wollen"]
 
 Das einzige Problem ist, dass die Blinkfrequenz zu schnell ist.
 Wir finden es viel angenehmer, 3 Sekunden statt 1 Sekunde zwischen den einzelnen Zustandsänderungen zu warten.

book/06-github/sections/3-maintaining.asc

@@ -73,7 +73,7 @@ In diesem Fall sollten Sie eine E-Mail erhalten, in der Sie über den neuen Pull
 
 [[_email_pr]]
 .E-Mail Benachrichtigung über einen neuen Pull-Request
-image::images/maint-01-email.png[Pull-Request, E-Mail Benachrichtigung]
+image::images/maint-01-email.png["Pull-Request, E-Mail Benachrichtigung"]
 
 Es gibt ein paar Punkte, die man bei dieser E-Mail beachten sollte.
 Es gibt ein kleines diffstat – eine Liste von Dateien, die sich im Pull Request geändert haben und um wieviel.

book/08-customizing-git/sections/attributes.asc

@@ -202,7 +202,7 @@ image::images/smudge.png[Der „smudge“ Filter wird beim Auschecken ausgeführ
 
 [[filters_b]]
 .Der „clean“ Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden
-image::images/clean.png[Der „clean“ Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden]
+image::images/clean.png["Der „clean“ Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden"]
 
 Die ursprüngliche Commit-Meldung dieser Funktion zeigt ein einfaches Anwendungsbeispiel, wie Sie Ihren gesamten C-Quellcode vor dem Commit durch das `indent` Programm laufen lassen können.
 Sie können es so einrichten, dass das Filterattribut in Ihrer `.gitattributes` Datei so gesetzt ist, dass `*.c` Dateien mit dem Filter „indent“ gefiltert werden: