Fix epubcheck errors (#425)

* Fix epubcheck errors

- Fix invalid width attributes in images
- Fix invalid URL with <user>/<project> placeholders
- Escape # characters in code examples to prevent invalid mark/strong tags
- Update alt text for basic-branching-2.png image

* Fix build errors

* Build Fehler gefixt

Author: pastatopf

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

@@ -42,7 +42,7 @@ $ git checkout iss53
 ----
 
 .Erstellen eines neuen Branch-Zeigers
-image::images/basic-branching-2.png[Erstellen eines neuen Branch-Zeigers]
+image::images/basic-branching-2.png[alt="Ein Commit-Verlauf mit einem Branch"]
 
 Du arbeitest an deiner Website und führst einige Commits durch.
 Sobald du das machst, bewegt das den `iss53` Branch vorwärts, weil du in ihn gewechselt (engl. checked out) bist. Das bedeutet, dein `HEAD` zeigt auf diesen Branch:
@@ -165,7 +165,7 @@ Da der Commit auf dem Branch, auf dem du dich gerade befindest, kein unmittelbar
 In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die das Branch-Ende und der gemeinsame Vorgänger 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 denselben Commit zeigt, auf dem du dich gegenwärtig befindest.
 
 .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 du gegenwärtig bist?
 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 dein `testing` Branch vorwärts bewegt hat, aber dein `master` Branch noch auf den Commit zeigt, auf dem du dich befandest, als du die Anweisung `git checkout` ausführtest, um die Branches zu wechseln.
 Lassen uns zum Branch `master` zurückwechseln.
@@ -137,7 +137,7 @@ Um alle Branches zu sehen, füge `--all` zu deinem Kommando `git log` hinzu.
 ====
 
 .HEAD bewegt sich, wenn du auscheckst
-image::images/checkout-master.png[HEAD bewegt sich, wenn du auscheckst]
+image::images/checkout-master.png[HEAD bewegt sich wenn du auscheckst]
 
 Diese Anweisung hat zwei Dinge bewirkt.
 Es bewegte den HEAD-Zeiger zurück, um auf den `master` Branch zu zeigen und es setzte die Dateien in deinem Arbeitsverzeichnis auf den Snapshot zurück, auf den `master` zeigt.

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

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

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

@@ -122,7 +122,7 @@ To https://github.com/tonychacon/blink
 
 Wenn wir nun zu unserem Fork auf GitHub zurückkehren, können wir sehen, dass GitHub bemerkt hat, dass wir einen neuen Feature-Branch gepusht haben. GitHub zeigt uns einen großen grünen Button, um unsere Änderungen zu überprüfen und einen Pull Request zum ursprünglichen Projekt zu öffnen.
 
-Du kannst alternativ auch die Seite „Branches“ bei `https://github.com/<user>/<project>/branches` aufzurufen, um deinen Branch auszuwählen und von dort aus einen neuen Pull Request zu öffnen.
+Du kannst alternativ auch die Seite „Branches" bei `https://github.com/user/project/branches` aufzurufen (ersetze `user` und `project` durch deine Werte), um deinen Branch auszuwählen und von dort aus einen neuen Pull Request zu öffnen.
 
 .Die Schaltfläche Pull Request
 image::images/blink-02-pr.png[Die Schaltfläche Pull Request]
@@ -303,8 +303,8 @@ Es stellt sich heraus, dass es viele, viele Möglichkeiten gibt, auf andere Ding
 Beginnen wir mit der Frage, wie man einen anderen Pull-Request oder ein Issue vergleicht.
 Alle Pull-Requests und Issues sind mit Nummern versehen und innerhalb des Projekts eindeutig.
 Beispielsweise ist es nicht möglich, Pull Request +#3+ _und_ Issue +#3+ anzulegen.
-Wenn du auf einen Pull-Request oder ein Issue von einem anderen verweisen möchtest, kannst du einfach `#<num>` in einen Kommentar oder eine Beschreibung eingeben.
-Du kannst auch präziser sein, wenn die Issue- oder Pull-Anforderung an einem anderen Ort liegen. Schreibe `Benutzername#<num>`, wenn du dich auf ein Issue oder Pull Request beziehst, in einen Fork des Repositorys, in dem du dich befindest. Oder schreibe `Benutzername/repo#<num>`, um auf etwas in einem anderen Repository zu verweisen.
+Wenn du auf einen Pull-Request oder ein Issue von einem anderen verweisen möchtest, kannst du einfach `+#<num>+` in einen Kommentar oder eine Beschreibung eingeben.
+Du kannst auch präziser sein, wenn die Issue- oder Pull-Anforderung an einem anderen Ort liegen. Schreibe `username#<num>`, wenn du dich auf ein Issue oder Pull Request beziehst, in einen Fork des Repositorys, in dem du dich befindest. Oder schreibe `username/repo#<num>`, um auf etwas in einem anderen Repository zu verweisen.
 
 Schauen wir uns ein Beispiel an.
 Angenommen, wir haben den Branch aus dem vorherigen Beispiel rebased, einen neuen Pull-Request für ihn erstellt und jetzt wollen wir die alte Pull-Anforderung aus der neuen aufrufen.

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

@@ -73,7 +73,7 @@ In diesem Fall solltest du eine E-Mail erhalten, in der du ü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[E-Mail Benachrichtigung eines neuen Pull Requests]
 
 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 wie sehr sie sich geändert haben.
@@ -149,7 +149,7 @@ Wenn sich das Repository auf GitHub befindet und es offnee Pull-Requests gibt,
 Das sind im Prinzip Branches, die aber nicht unter `refs/heads/` stehen. Sie werden normalerweise nicht angezeigt, wenn du klonst oder vom Server fetchst – der Fetching-Prozess ignoriert sie normalerweise.
 
 Es gibt zwei Referenzen pro Pull-Request – eine endet mit `/head`. Sie zeigt auf genau den gleichen Commit wie der letzte Commit im Pull-Request-Branch.
-Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch `bug-fix` heißt, der auf `a5a775` zeigt, dann haben wir in *unserem* Repository keinen `bug-fix` Branch (weil der in *seinem* Fork liegt). Wir haben jedoch `pull/<pr#>/head`, der auf `a5a775` zeigt.
+Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch `bug-fix` heißt, der auf `a5a775` zeigt, dann haben wir in *unserem* Repository keinen `bug-fix` Branch (weil der in *seinem* Fork liegt). Wir haben jedoch `pull/\<pr#>/head`, der auf `a5a775` zeigt.
 Das heißt, wir können jeden Pull-Request-Branch herunterladen, ohne lokal einen Menge Remotes hinzufügen zu müssen.
 
 Jetzt kannst du das Fetchen dieser Referenz direkt durchführen.
@@ -215,7 +215,7 @@ Switched to a new branch 'pr/2'
 ----
 
 Diejenigen mit Adleraugen unter euch werden das `head` am Ende des Remote-Abschnitts der refspec bemerkt haben.
-Es gibt auch ein `refs/pull/#/merge` ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge“ klickst. 
+Es gibt auch ein `refs/pull/\<num>/merge` ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge" klickst.
 Auf diese Weise kannst du das Ergebnis des Pull-Requests testen, bevor du überhaupt auf die Schaltfläche geklickt hast.
 
 ===== Pull-Requests auf Pull-Requests

book/07-git-tools/sections/rerere.asc

@@ -209,7 +209,7 @@ index a440db6,54336ba..0000000
 
 
 .Automatisch aufgelöster merge Konflikt, der eine vorherige Auflösung nutzt
-image::images/rerere3.png[Automatisch aufgelöster merge Konflikt, der eine vorherige Auflösung nutzt]
+image::images/rerere3.png[Automatisch aufgelöster merge Konflikt der eine vorherige Auflösung nutzt]
 
 Du kannst den Status der Konfliktdatei auch mit `git checkout` wiederherstellen:
 

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

@@ -200,8 +200,8 @@ Diese Filter können so eingestellt werden, um damit alle möglichen interessant
 image::images/smudge.png[Der „smudge“ Filter wird beim Auschecken ausgeführt]
 
 [[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]
+.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 du deinen C-Quellcode vor dem Commit durch das `indent` Programm laufen lassen kannst.
 Du kannst es so einrichten, dass das Filterattribut in deiner `.gitattributes` Datei so gesetzt ist, dass `*.c` Dateien mit dem Filter „indent“ gefiltert werden:

book/10-git-internals/sections/environment.asc

@@ -54,8 +54,8 @@ Wenn du viele Projekte mit großen Dateien hast, die genau den gleichen Inhalt h
 Diese werden in der Datei `.gitignore` aber auch in der Befehlszeile (`git add *.c`) verwendet.
 
 *`GIT_GLOB_PATHSPECS`* und *`GIT_NOGLOB_PATHSPECS`* steuern das Standardverhalten von Platzhaltern in Pfadangaben.
-Wenn `GIT_GLOB_PATHSPECS` auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn `GIT_NOGLOB_PATHSPECS` auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass `*.c` nur mit einer Datei namens „* .c“ übereinstimmt und nicht mit einer Datei, deren Name mit `.c` endet.
-Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit `:(glob)` oder `:(literal)` beginnst, wie in `:(glob)*.c`.
+Wenn `GIT_GLOB_PATHSPECS` auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn `GIT_NOGLOB_PATHSPECS` auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass `\*.c` nur mit einer Datei namens „*.c" übereinstimmt und nicht mit einer Datei, deren Name mit `.c` endet.
+Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit `:(glob)` oder `:(literal)` beginnst, wie in `:(glob)\*.c`.
 
 *`GIT_LITERAL_PATHSPECS`* deaktiviert beide oben genannten Verhaltensweisen. Es können keine Platzhalterzeichen verwendet werden, und die Präfixe zum Überschreiben sind ebenfalls deaktiviert.