'what is git' build error (#174)

* Changes from July 3rd on original repo

* Changes from July 4th on original repo

* Pull Request 1450

* Pull Request 1470

* pull request 1469

* pull request 1468

* pull request 1477

* pull request 1477

* pull request 1485

* pull request 1481

* pull request 1483

* pull request 1483

* pull request 1484

* pull request 1476

* pull request 1489

* pull request 1489

* pull request 1490

* pull request 1506

* reference to what_is_git_section corrected

Author: pastatopf

book/01-introduction/sections/what-is-git.asc

@@ -1,4 +1,4 @@
-[[_what_is_git]]
+[[what_is_git_section]]
 === Was ist Git?
 
 Also, was ist Git in Kürze?

book/02-git-basics/sections/tagging.asc

@@ -263,16 +263,19 @@ Wenn Sie die Dateiversion anzeigen möchten, auf die ein bestimmter Tag zeigt, k
 [source,console]
 ----
 $ git checkout v2.0.0
-Note: checking out 'v2.0.0'.
+Note: switching to 'v2.0.0'.
 
 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:
+do so (now or later) by using -c with the switch command. Example:
 
-  git checkout -b <new-branch>
+  git switch -c <new-branch-name>
+Or undo this operation with:
+  git switch -
+Turn off this advice by setting config variable advice.detachedHead to false
 
 HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final
 

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

@@ -3,13 +3,13 @@
 
 Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Schritt zurücktreten und untersuchen, wie Git seine Daten speichert.
 
-Wie Sie vielleicht aus Kapitel 1 <<ch01-getting-started#_what_is_git>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von _Snapshots_.
+Wie Sie vielleicht aus Kapitel 1 <<ch01-getting-started#what_is_git_section>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von _Snapshots_.
 
 Wenn Sie einen Commit durchführen, speichert Git ein Commit-Objekt, das einen Zeiger auf den Snapshot des von Ihnen bereitgestellten Inhalts enthält.
 Dieses Objekt enthält auch den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und zeigt auf den Commit oder die Commits, die direkt vor diesem Commit stattfanden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welcher aus dem Zusammenführen (engl. mergen) von zwei oder mehr Branches resultiert.
 
 Um das zu veranschaulichen, lassen Sie uns annehmen, Sie haben ein Verzeichnis, welches drei Dateien enthält, und Sie fügen alle Dateien zur Staging-Area hinzu und führen einen Commit durch.
-Durch das Hinzufügen der Dateien zur Staging-Area erzeugt Git für jede Datei eine Prüfsumme (den SHA-1-Hashwert, den wir in Kapitel 1 <<ch01-getting-started#_what_is_git>> erwähnt haben), speichert diese Version der Datei im Git-Repository (Git verweist auf diese als _blobs_) und fügt die Prüfsumme der Staging-Area hinzu:
+Durch das Hinzufügen der Dateien zur Staging-Area erzeugt Git für jede Datei eine Prüfsumme (den SHA-1-Hashwert, den wir in Kapitel 1 <<ch01-getting-started#what_is_git_section>> erwähnt haben), speichert diese Version der Datei im Git-Repository (Git verweist auf diese als _blobs_) und fügt die Prüfsumme der Staging-Area hinzu:
 
 [source,console]
 ----