Typografische Fixes

Bindestriche und Anführungszeichen korrigiert

Author: max123kl

TRANSLATION_NOTES_DE.asc

@@ -121,11 +121,11 @@ Projektbetreuer
 |to maintain|
 betreuen
 |to merge|
-mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "zusammenführen oder verschmelzen" verwendet werden.
+mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „zusammenführen oder verschmelzen“ verwendet werden.
 |namespace|
-namespace; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Namensraum" verwendet werden.
+namespace; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Namensraum“ verwendet werden.
 |packfile|
-packfile; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Paketdatei" verwendet werden.
+packfile; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Paketdatei“ verwendet werden.
 |Patch|
 Änderung oder auch Patch
 |Porcelain commands|
@@ -147,9 +147,9 @@ pushen; er/sie pusht; wir pushen; Deutsch: hochladen
 |==============================================================================
 |Englisch|Deutsch
 |to rebase|
-rebasen; er/sie rebaset, wir rebasen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "reorganisieren oder restrukturieren" verwendet werden.
+rebasen; er/sie rebaset, wir rebasen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „reorganisieren oder restrukturieren“ verwendet werden.
 |refspec|
-refspec; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Referenzspezifikation" verwendet werden.
+refspec; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Referenzspezifikation“ verwendet werden.
 |Repository|
 Repository; Singular: das Repository; Plural: die Repositorys; **Nicht** Repositor**ie**s,
 siehe hierzu auch link:http://www.duden.de/sprachwissen/sprachratgeber/crashkurs--in-25-schritten-zur-neuen-rechtschreibung[folgender Link]
@@ -160,7 +160,7 @@ SHA1 Hash; Singular: der SHA1 Hash; Plural: die SHA1 Hashes
 |to share|
 teilen
 |Snapshot|
-Snapshot; Singular: der Snapshot; Plural: die Snapshots; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Schnappschuss" verwendet werden.
+Snapshot; Singular: der Snapshot; Plural: die Snapshots; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Schnappschuss“ verwendet werden.
 |to squah|
 squashen; er/sie squasht, wir squashen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „komprimieren“ verwendet werden.
 |to stage|

book/02-git-basics/sections/getting-a-repository.asc

@@ -60,7 +60,7 @@ Wenn Sie eine Kopie eines existierenden Git Repositorys anlegen wollen – um be
 Wenn Sie bereits Erfahrung mit einem anderen VCS System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet.
 Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten – Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner.
 Jede Version von jeder Datei der Projekt-Historie wird automatisch heruntergeladen, wenn Sie `git clone` ausführen.
-Wenn Ihre Serverfestplatte beschädigt wird, können Sie oft nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden - siehe Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, für weitere Details).
+Wenn Ihre Serverfestplatte beschädigt wird, können Sie oft nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden – siehe Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, für weitere Details).
 
 Sie können ein Repository mit dem Befehl `git clone [url]` klonen.(((Git Befehle, clone)))
 Um beispielsweise das Repository der verlinkbaren Git Bibliothek `libgit2` zu klonen, führen Sie den folgenden Befehl aus:

book/02-git-basics/sections/recording-changes.asc

@@ -500,7 +500,7 @@ Das ist bequem, aber seien Sie vorsichtig. Manchmal führt dieses Flag dazu, das
 Um eine Datei aus Git zu entfernen, müssen Sie sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen.
 Der Befehl `git rm` erledigt das und entfernt die Datei auch aus Ihrem Arbeitsverzeichnis, so dass Sie sie beim nächsten Mal nicht mehr als „untracked“ Datei sehen.
 
-Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem "Changes not staged for commit"-Bereich (das ist die _unstaged_-Area) Ihrer `git status`-Ausgabe:
+Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem „Changes not staged for commit“ Bereich (das ist die _unstaged_-Area) Ihrer `git status`-Ausgabe:
 
 [source,console]
 ----
@@ -607,5 +607,5 @@ $ git add README
 ----
 
 Git erkennt, dass es sich um eine umbenannte Datei handelt, so dass es egal ist, ob Sie eine Datei auf diese Weise oder mit dem Befehl `mv` umbenennen.
-Der alleinige, reale Unterschied ist, dass `git mv` ein einziger Befehl ist statt deren drei - es ist eine Komfortfunktion.
+Der alleinige, reale Unterschied ist, dass `git mv` ein einziger Befehl ist statt deren drei – es ist eine Komfortfunktion.
 Wichtiger ist, dass Sie jedes beliebige Tool verwenden können, um eine Datei umzubenennen und das add/rm später aufrufen können, bevor Sie committen.

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

@@ -216,7 +216,7 @@ paul
 Es ist zu beachten, dass dadurch auch alle Ihre Remote-Tracking-Branchnamen geändert werden.
 Was früher mit `pb/master` angesprochen wurde, ist jetzt `paul/master`.
 
-Wenn Sie einen Remote aus irgendwelchen Gründen entfernen möchten – Sie haben den Server verschoben oder verwenden einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei - dann können Sie entweder `git remote remove` oder `git remote rm` verwenden:
+Wenn Sie einen Remote aus irgendwelchen Gründen entfernen möchten – Sie haben den Server verschoben oder verwenden einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann können Sie entweder `git remote remove` oder `git remote rm` verwenden:
 
 [source,console]
 ----

book/02-git-basics/sections/viewing-history.asc

@@ -181,7 +181,7 @@ a11bef0 - Scott Chacon, 6 years ago : first commit
 
 Sie fragen sich vielleicht, worin der Unterschied zwischen _Autor_ und _Committer_ besteht.
 Der Autor ist die Person, die das Werk ursprünglich geschrieben hat, während der Committer die Person ist, die das Werk zuletzt bearbeitet hat.
-Wenn Sie also einen Patch an ein Projekt senden und eines der Core-Mitglieder den Patch einbindet, erhalten Sie beide die Anerkennung - Sie als Autor und das Core-Mitglied als Committer.
+Wenn Sie also einen Patch an ein Projekt senden und eines der Core-Mitglieder den Patch einbindet, erhalten Sie beide die Anerkennung – Sie als Autor und das Core-Mitglied als Committer.
 Wir werden diese Unterscheidung näher erläutern in Kapitel 5, <<ch05-distributed-git#ch05-distributed-git,Verteiltes Git>>.
 
 Die Optionen `oneline` und `format` sind vor allem bei einer anderen `log`-Option mit Bezeichnung `--graph` hilfreich.

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

@@ -145,7 +145,7 @@ Wenn Sie diese Änderungen übernehmen müssen, können Sie in Ihren `master`-Br
 ==== Einfaches Merging
 
 (((branches, merging)))(((merging)))
-Angenommen, Sie haben entschieden, dass Ihr Issue #53 abgeschlossen ist und Sie bereit sind, ihn in Ihren "Master"-Zweig zu integrieren.
+Angenommen, Sie haben entschieden, dass Ihr Issue #53 abgeschlossen ist und Sie bereit sind, ihn in Ihren „Master“ Branch zu integrieren.
 Dann werden Sie Ihren `iss53`-Branch in den `master`-Branch mergen, so wie Sie es zuvor mit dem `hotfix`-Branch gemacht haben.
 Sie müssen nur mit der Anweisung `checkout` zum dem Branch zu wechseln, in welchen Sie etwas einfließen lassen wollen und dann die Anweisung `git merge` ausführen:
 

book/03-git-branching/sections/remote-branches.asc

@@ -112,7 +112,7 @@ From https://github.com/schacon/simplegit
 ----
 
 Es ist wichtig zu wissen, dass, wenn Sie einen Fetch durchführen, dass neue Remote-Tracking-Branches heruntergeladen werden, Sie nicht automatisch lokale, bearbeitbare Kopien von ihnen haben.
-Mit anderen Worten, in diesem Fall haben Sie keinen neuen Branch `serverfix` - Sie haben nur einen Zeiger `origin/serverfix`, den Sie nicht ändern können.
+Mit anderen Worten, in diesem Fall haben Sie keinen neuen Branch `serverfix` – Sie haben nur einen Zeiger `origin/serverfix`, den Sie nicht ändern können.
 
 Um diese Änderungen in Ihren gegenwärtigen Arbeitsbranch einfließen zu lassen, können Sie die Anweisung `git merge origin/serverfix` ausführen.
 Wenn Sie Ihren eigenen `serverfix` Branch haben wollen, an dem Sie arbeiten können, können Sie ihn von Ihrem Remote-Tracking-Branch ableiten (engl. base):

book/04-git-server/sections/gitlab.asc

@@ -21,7 +21,7 @@ image::images/bitnami.png[Der Anmeldebildschirm für die virtuelle Maschine von
 
 Für alles andere beachten Sie bitte die Hinweise in der Readme-Datei der GitLab Community Edition, die Sie unter https://gitlab.com/gitlab-org/gitlab-ce/tree/master finden.
 Dort finden Sie Hilfe bei der Installation von GitLab mit Kochrezepten, einer virtuellen Maschine auf Digital Ocean und RPM- und DEB-Paketen (die sich derzeit in der Beta-Version befinden).
-Es gibt auch „inoffizielle“ Anleitungen, wie Sie GitLab mit nicht standardmäßigen Betriebssystemen und Datenbanken zum Laufen bringen können - dazu ein vollständig manuelles Installationsskript und viele andere Inhalte.
+Es gibt auch „inoffizielle“ Anleitungen, wie Sie GitLab mit nicht standardmäßigen Betriebssystemen und Datenbanken zum Laufen bringen können – dazu ein vollständig manuelles Installationsskript und viele andere Inhalte.
 
 ==== Administration
 
@@ -120,7 +120,7 @@ Indem ein Benutzer eine Zugriffsebene von „Developer“ oder höher erhält, k
 Eine weitere, stärker entkoppelte Art der Zusammenarbeit ist die Nutzung von Merge-Anfragen.
 Diese Funktion ermöglicht es jedem Benutzer, der ein Projekt sehen kann, kontrolliert dazu beizutragen.
 Benutzer mit direktem Zugriff können einfach einen Branch erstellen, Commits auf ihn verschieben und einen Merge-Request von ihrem Branch zurück in den `master` oder einen anderen Branch einreichen.
-Benutzer, die keine Push-Berechtigungen für ein Repository haben, können es „forken“ (ihre eigene Kopie erstellen), Push-Commits für _diese_ Kopie erstellen und einen Merge-Request von ihrer Fork zurück zum Hauptprojekt anfordern. 
+Benutzer, die keine Push-Berechtigungen für ein Repository haben, können es „forken“ (ihre eigene Kopie erstellen), Push-Commits für _diese_ Kopie erstellen und einen Merge-Request von ihrer Fork zurück zum Hauptprojekt anfordern.
 Dieses Modell ermöglicht es dem Eigentümer, die volle Kontrolle darüber zu behalten, was wann in das Repository gelangt, und gleichzeitig Beiträge von unbekannten Benutzern zu ermöglichen.
 
 Merge-Requests und Issues sind die Hauptelemente der langjährigen Zusammenarbeit in GitLab.