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

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:

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]

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

@@ -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