Merge pull request #141 from max123kl/unschöne_Divis

Divis nach monospaced Text entfernt

Author: max123kl

C-git-commands.asc

@@ -261,7 +261,7 @@ Obwohl er an verschiedenen Stellen im Buch verwendet wird, gibt es nur sehr weni
 
 Wir haben am Ende von <<ch05-distributed-git#_public_project>> beschrieben, wie man ein Squashed Merge macht (bei dem Git die Arbeit zusammenführt, sich aber so verhält, als wäre es nur ein neuer Commit, ohne die Historie des Branches, in dem man zusammenführt, aufzuzeichnen).
 
-Wir haben in <<ch07-git-tools#_advanced_merging>> viel über den Merge-Prozess und -Befehl berichtet, einschließlich des Befehls `-Xignore-space-change` und des `--abort`-Flags, um ein Merge-Problem abzubrechen.
+Wir haben in <<ch07-git-tools#_advanced_merging>> viel über den Merge-Prozess und -Befehl berichtet, einschließlich des Befehls `-Xignore-space-change` und des Flags `--abort`, um ein Merge-Problem abzubrechen.
 
 Wir haben in <<ch07-git-tools#_signing_commits>> gelernt, wie man Signaturen vor dem Zusammenführen überprüft, wenn Ihr Projekt GPG-Signaturen verwendet.
 

book/01-introduction/sections/first-time-setup.asc

@@ -19,7 +19,7 @@ Die Konfiguration ist an drei verschiedenen Orten gespeichert:
 
   Jede Ebene überschreibt Werte der vorherigen Ebene, so dass Werte in `.git/config` diejenigen in `/etc/gitconfig` aushebeln.
 
-Auf Windows-Systemen sucht Git nach der Datei `.gitconfig` im `$HOME`-Verzeichnis (normalerweise zeigt `$HOME` bei den meisten Systemen auf `C:\Users\$USER`).
+Auf Windows-Systemen sucht Git nach der Datei `.gitconfig` im `$HOME` Verzeichnis (normalerweise zeigt `$HOME` bei den meisten Systemen auf `C:\Users\$USER`).
 Git schaut immer nach `/etc/gitconfig`, auch wenn die sich relativ zu dem MSys-Wurzelverzeichnis befindet, dem Verzeichnis in das Sie Git installiert haben.
 Wenn Sie eine Version 2.x oder neuer von Git für Windows verwenden, gibt es auch eine Konfigurationsdatei auf Systemebene unter
 `C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Git\config` unter Windows XP und unter `C:\ProgramData\Git\config` unter Windows Vista und neuer.
@@ -44,7 +44,7 @@ $ git config --global user.email [email protected]
 ----
 
 Wie schon erwähnt, brauchen Sie diese Konfiguration nur einmal vorzunehmen, wenn Sie die Option `--global` verwenden. Auf Grund der oben erwähnten Prioritäten gilt das dann für alle Ihre Projekte.
-Wenn Sie für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail-Adresse verwenden möchten, können Sie den Befehl ohne die `--global`-Option innerhalb des Projektes ausführen.
+Wenn Sie für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail-Adresse verwenden möchten, können Sie den Befehl ohne die Option `--global` innerhalb des Projektes ausführen.
 
 Viele der grafischen Oberflächen helfen einem bei diesem Schritt, wenn Sie sie zum ersten Mal ausführen.
 

book/01-introduction/sections/help.asc

@@ -10,7 +10,7 @@ $ git <verb> --help
 $ man git-<verb>
 ----
 
-Beispielweise erhalten Sie die Hilfeseite für den `git config`-Befehl folgendermaßen:(((Git Befehle, help)))
+Beispielweise erhalten Sie die Hilfeseite für den Befehl `git config` folgendermaßen:(((Git Befehle, help)))
 
 [source,console]
 ----

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

@@ -60,7 +60,7 @@ Date:   Tue Aug 26 19:48:51 2008 +0800
 
 Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alias, für den Sie ihn verwenden.
 Vielleicht möchten Sie jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen.
-In diesem Fall starten Sie den Befehl mit einem `!`-Zeichen.
+In diesem Fall starten Sie den Befehl mit einem Ausrufezeichen (`!`).
 Das ist hilfreich, wenn Sie Ihre eigenen Tools schreiben, die mit einem Git-Repository arbeiten.
 Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasieren:
 

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

@@ -38,7 +38,7 @@ $ git init
 
 Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git-Repository-Daten enthalten sind, also ein Git-Repository Grundgerüst.
 Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert.
-In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Interna>>, finden Sie weitere Informationen, welche Dateien im `.git`-Verzeichnis enthalten sind und was ihre Aufgabe ist.(((Git Befehle, init)))
+In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Interna>>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.(((Git Befehle, init)))
 
 Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit starten.
 Mit dem Befehl `git add` legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugen Sie einen neuen Commit:
@@ -70,8 +70,8 @@ Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu kl
 $ git clone https://github.com/libgit2/libgit2
 ----
 
-Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git`-Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Arbeitskopie der aktuellsten Version aus.
-Wenn Sie in das neue `libgit2`-Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten.
+Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Arbeitskopie der aktuellsten Version aus.
+Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten.
 
 Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchten, können Sie das wie folgt durchführen:
 
@@ -83,5 +83,5 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit
 Dieser Befehl tut das Gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal `mylibgit`.
 
 Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle.
-Das vorhergehende Beispiel verwendet das `https://`-Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet.
+Das vorhergehende Beispiel verwendet das `https://` Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet.
 Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, stellt alle verfügbaren Optionen vor, die der Server für den Zugriff auf Ihr Git-Repository hat und die Vor- und Nachteile der einzelnen Optionen, die man einrichten kann.

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

@@ -62,14 +62,14 @@ Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie
 ==== Neue Dateien zur Versionsverwaltung hinzufügen
 
 Um eine neue Datei zu versionieren, können Sie den Befehl `git add` verwenden.(((Git Befehle, add)))
-Für Ihre neue `README`-Datei, können Sie folgendes ausführen:
+Für Ihre neue `README` Datei, können Sie folgendes ausführen:
 
 [source,console]
 ----
 $ git add README
 ----
 
-Wenn Sie erneut den Befehl `git status` ausführen, werden Sie sehen, dass sich Ihre `README`-Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist:
+Wenn Sie erneut den Befehl `git status` ausführen, werden Sie sehen, dass sich Ihre `README` Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist:
 
 [source,console]
 ----
@@ -86,7 +86,7 @@ Changes to be committed:
 Sie können erkennen, dass die Datei für den nächsten Commit vorgemerkt ist, weil sie unter der Rubrik „Changes to be committed“ aufgelistet ist.
 Wenn Sie jetzt einen Commit anlegen, wird der Schnappschuss den Zustand der Datei festhalten, den sie zum Zeitpunkt des Befehls `git add` hat.
 Sie erinnern sich vielleicht daran, wie Sie vorhin `git init` und anschließend `git add <files>` ausgeführt haben. Mit diesen Befehlen haben Sie die Dateien in Ihrem Verzeichnis zur Versionsverwaltung hinzugefügt.(((Git Befehle, init)))(((Git Befehle, add)))
-Der `git add`-Befehl akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn Sie ein Verzeichnis angeben, fügt `git add` alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu.
+Der Befehl `git add` akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn Sie ein Verzeichnis angeben, fügt `git add` alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu.
 
 ==== Geänderte Dateien zur Staging-Area hinzufügen
 
@@ -203,7 +203,7 @@ Das `Rakefile` wurde modifiziert, staged und dann wieder modifiziert, so dass es
 Häufig gibt es eine Reihe von Dateien, die Git nicht automatisch hinzufügen oder schon gar nicht als „nicht versioniert“ (eng. untracked) anzeigen soll.
 Dazu gehören in der Regel automatisch generierte Dateien, wie Log-Dateien oder Dateien, die von Ihrem Build-System erzeugt werden.
 In solchen Fällen können Sie die Datei `.gitignore` erstellen, die eine Liste mit Vergleichsmustern enthält.(((ignorieren von Dateien)))(((Dateien, ignorieren)))
-Hier ist eine `.gitignore`-Beispieldatei:
+Hier ist eine `.gitignore` Beispieldatei:
 
 [source,console]
 ----
@@ -215,7 +215,7 @@ $ cat .gitignore
 Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf „.o“ oder „.a“ enden – Objekt- und Archivdateien, die das Ergebnis der Codegenerierung sein könnten.
 Die zweite Zeile weist Git an, alle Dateien zu ignorieren, deren Name mit einer Tilde (`~`) enden, was von vielen Texteditoren wie Emacs zum Markieren temporärer Dateien verwendet wird.
 Sie können auch ein Verzeichnis „log“, „tmp“ oder „pid“ hinzufügen, eine automatisch generierte Dokumentation usw.
-Es ist im Allgemeinen eine gute Idee, die `.gitignore`-Datei für Ihr neues Repository einzurichten, noch bevor Sie loslegen. So können Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten.
+Es ist im Allgemeinen eine gute Idee, die `.gitignore` Datei für Ihr neues Repository einzurichten, noch bevor Sie loslegen. So können Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten.
 
 Die Richtlinien für Vergleichsmuster, die Sie in der Datei `.gitignore` eingeben können, lauten wie folgt:
 
@@ -229,7 +229,7 @@ Platzhalter-Zeichen sind wie einfache, reguläre Ausdrücke, die von der Shell g
 Ein Sternchen (`*`) entspricht null oder mehr Zeichen; `[abc]` entspricht jedem Zeichen innerhalb der eckigen Klammern (in diesem Fall a, b oder c); ein Fragezeichen (`?`) entspricht einem einzelnen Zeichen und eckige Klammern, die durch einen Bindestrich (`[0-9]`) getrennte Zeichen einschließen, passen zu jedem Zeichen dazwischen (in diesem Fall von 0 bis 9).
 Sie können auch zwei Sterne verwenden, um verschachtelte Verzeichnisse abzugleichen; `a/**/z` würde zu `a/z`, `a/b/z`, `a/b/c/z` usw. passen.
 
-Hier ist eine weitere `.gitignore`-Beispieldatei:
+Hier ist eine weitere `.gitignore` Beispieldatei:
 
 [source]
 ----
@@ -254,17 +254,17 @@ doc/**/*.pdf
 
 [TIP]
 ====
-GitHub unterhält eine ziemlich umfassende Liste guter `.gitignore`-Beispiel-Dateien für Dutzende von Projekten und Sprachen auf https://github.com/github/gitignore[], falls Sie einen Ansatzpunkt für Ihr Projekt suchen.
+GitHub unterhält eine ziemlich umfassende Liste guter `.gitignore` Beispiel-Dateien für Dutzende von Projekten und Sprachen auf https://github.com/github/gitignore[], falls Sie einen Ansatzpunkt für Ihr Projekt suchen.
 ====
 
 [NOTE]
 ====
-Im einfachsten Fall kann ein Repository eine einzelne `.gitignore`-Datei in seinem Root-Verzeichnis haben, die rekursiv für das gesamte Repository gilt.
-Es ist aber auch möglich, weitere `.gitignore`-Dateien in Unterverzeichnissen anzulegen.
-Die Regeln dieser verschachtelten `.gitignore`-Dateien gelten nur für die in dem Verzeichnis (und unterhalb) liegenden Dateien.
-Das Linux-Kernel-Source-Repository hat beispielsweise 206 `.gitignore`-Dateien.
+Im einfachsten Fall kann ein Repository eine einzelne `.gitignore` Datei in seinem Root-Verzeichnis haben, die rekursiv für das gesamte Repository gilt.
+Es ist aber auch möglich, weitere `.gitignore` Dateien in Unterverzeichnissen anzulegen.
+Die Regeln dieser verschachtelten `.gitignore` Dateien gelten nur für die in dem Verzeichnis (und unterhalb) liegenden Dateien.
+Das Linux-Kernel-Source-Repository hat beispielsweise 206 `.gitignore` Dateien.
 
-Es würde den Rahmen dieses Buches sprengen, detaillierter auf den Einsatz mehrerer `.gitignore`-Dateien einzugehen; siehe die Manpage `man gitignore` für weitere Informationen.
+Es würde den Rahmen dieses Buches sprengen, detaillierter auf den Einsatz mehrerer `.gitignore` Dateien einzugehen; siehe die Manpage `man gitignore` für weitere Informationen.
 ====
 
 [[_git_diff_staged]]
@@ -509,7 +509,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]
 ----
@@ -547,7 +547,7 @@ Hierbei handelt es sich um eine Sicherheitsfunktion, die ein versehentliches Ent
 
 Eine weitere nützliche Sache, die Sie möglicherweise nutzen möchten, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus Ihrer Staging-Area zu entfernen.
 Mit anderen Worten, Sie können die Datei auf Ihrer Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen.
-Das ist besonders dann nützlich, wenn Sie vergessen haben, etwas zu Ihrer `.gitignore`-Datei hinzuzufügen und diese versehentlich „gestaged“ haben, wie eine große Logdatei oder eine Reihe von `.a`-kompilierten Dateien.
+Das ist besonders dann nützlich, wenn Sie vergessen haben, etwas zu Ihrer `.gitignore` Datei hinzuzufügen und diese versehentlich „gestaged“ haben, wie eine große Logdatei oder eine Reihe von `.a`-kompilierten Dateien.
 Das erreichen Sie mit der Option `--cached`:
 
 [source,console]

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

@@ -71,7 +71,7 @@ Beachten Sie, dass diese Remotes eine Vielzahl von Protokollen verwenden; wir we
 
 ==== Hinzufügen von Remote-Repositorys
 
-Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl `git clone` stillschweigend den `origin`-Remote für Sie hinzufügt.
+Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl `git clone` stillschweigend den Remote `origin` für Sie hinzufügt.
 So können Sie explizit einen neuen Remote hinzufügen.(((Git Befehle, remote)))
 Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das Sie leicht verweisen können, führen Sie `git remote add <shortname> <url>` aus:
 
@@ -102,7 +102,7 @@ From https://github.com/paulboone/ticgit
  * [new branch]      ticgit     -> pb/ticgit
 ----
 
-Pauls `master`-Branch ist nun lokal als `pb/master` erreichbar – Sie können ihn in eine Ihrer Branches einbinden, oder Sie können an dieser Stelle in einen lokalen Branch wechseln (engl. checkout), wenn Sie ihn inspizieren möchten.
+Pauls `master` Branch ist nun lokal als `pb/master` erreichbar – Sie können ihn in eine Ihrer Branches einbinden, oder Sie können an dieser Stelle in einen lokalen Branch wechseln (engl. checkout), wenn Sie ihn inspizieren möchten.
 (Wir werden in <<ch03-git-branching#ch03-git-branching,Git Branching>> näher darauf eingehen, was Branches sind und wie man sie viel präziser nutzen kann.)
 
 [[_fetching_and_pulling]]
@@ -124,15 +124,15 @@ Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in
 Sie müssen das Ganze manuell mit Ihrer Arbeit zusammenführen, wenn Sie fertig sind.
 
 Wenn Ihr aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), können Sie den Befehl `git pull` verwenden, um diesen entfernten Branch automatisch zu holen und dann mit Ihrem aktuellen Branch zusammenzuführen (siehe den nächsten Abschnitt und <<ch03-git-branching#ch03-git-branching,Git Branching>> für weitere Informationen).(((Git Befehle, pull)))
-Das könnte ein einfacherer oder komfortablerer Workflow für Sie sein. Standardmäßig richtet der Befehl `git clone` Ihren lokalen `master`-Branch automatisch so ein, dass er den entfernten `master`-Branch (oder wie auch immer der Standard-Branch genannt wird) auf dem Server versioniert, von dem Sie geklont haben.
+Das könnte ein einfacherer oder komfortablerer Workflow für Sie sein. Standardmäßig richtet der Befehl `git clone` Ihren lokalen `master` Branch automatisch so ein, dass er den entfernten `master` Branch (oder wie auch immer der Standard-Branch genannt wird) auf dem Server versioniert, von dem Sie geklont haben.
 Wenn Sie `git pull` ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben, und es wird automatisch versucht, sie in den Code zu mergen, an dem Sie gerade arbeiten.
 
 [[_pushing_remotes]]
 ==== Zu Ihren Remotes Pushen
 
 Wenn Sie Ihr Projekt an einem bestimmten Punkt haben, den Sie teilen möchten, müssen Sie es zum Upstream verschieben (engl. pushen).
 Der Befehl dafür ist einfach: `git push <remote> <branch>`.(((Git Befehle, push)))
-Wenn Sie Ihren `master`-Branch auf Ihren `origin`-Server verschieben möchten (nochmals, das Klonen richtet im Regelfall beide dieser Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen:
+Wenn Sie Ihren `master` Branch auf Ihren `origin` Server verschieben möchten (nochmals, das Klonen richtet im Regelfall beide dieser Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen:
 
 [source,console]
 ----
@@ -167,7 +167,7 @@ $ git remote show origin
 ----
 
 Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branchen auf.
-Der hilfreiche Befehl teilt Ihnen mit, dass, wenn Sie sich im `master`-Branch befinden und falls Sie `git pull` ausführen, dieser automatisch im Master-Zweig des Remote gemergt wird, nachdem er alle Remote-Referenzen abgerufen (engl. fetched) hat.
+Der hilfreiche Befehl teilt Ihnen mit, dass, wenn Sie sich im `master` Branch befinden und falls Sie `git pull` ausführen, dieser automatisch im Master-Zweig des Remote gemergt wird, nachdem er alle Remote-Referenzen abgerufen (engl. fetched) hat.
 Er listet auch alle Remote-Referenzen auf, die er abgerufen hat.
 
 Das ist nur ein einfaches Beispiel, auf das Sie vermutlich treffen werden.

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

@@ -87,7 +87,7 @@ Die Datei `CONTRIBUTING.md` wurde modifiziert, aber erneut im Status unstaged.
 
 [NOTE]
 =====
-Es ist wahr, dass `git reset` ein riskanter Befehl sein kann, besonders, wenn Sie das `--hard`-Flag mitgeben.
+Es ist wahr, dass `git reset` ein riskanter Befehl sein kann, besonders, wenn Sie das `--hard` Flag mitgeben.
 In dem oben beschriebenen Szenario wird die Datei in Ihrem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist.
 =====