Merge pull request #108 from saxc/fix-spelling-c7

Fix spelling, chapter 7

Author: max123kl

book/07-git-tools/sections/advanced-merging.asc

@@ -96,7 +96,7 @@ index ac51efd..36c06c8 100755
  1 file changed, 1 insertion(+)
 ----
 
-Jetzt wechseln wir wieder zu unserem Branch `master` und fügen einige Kommentare für die Funktion hinzu.
+Jetzt versuchen wir unseren `whitespace` branch zu mergen, es kommt zu einem Konflikt wegen der Änderungen an den Whitespaces (dt. Leerzeichen).
 
 [source,console]
 ----

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

@@ -14,7 +14,7 @@ Git hat ein paar Optionen im Angebot:
   Bei jeder Verbindung wird nach Ihrem Benutzernamen und Passwort gefragt.
 * Der „Cache“-Modus hält die Anmeldedaten für eine gewisse Zeitspanne im Zwischenspeicher.
 Keines der Passwörter wird jemals auf der Festplatte abgelegt und nach 15 Minuten werden sie aus dem Cache gelöscht.
-* Der „Speicher“-Modus speichert die Zugangsdaten in einer Klartextdatei auf der Festplatte, und sie verfallen nie.
+* Der „Speicher“-Modus speichert die Zugangsdaten in einer Klartextdatei auf der Festplatte und sie verfallen nie.
 Das bedeutet, dass Sie Ihre Anmeldedaten nie wieder eingeben müssen, bis Sie Ihr Passwort für den Git-Host ändern.
 Der Nachteil dieses Ansatzes ist, dass Ihre Passwörter im Klartext in einer einfachen Datei in Ihrem Homeverzeichnis gespeichert werden.
 * Wenn Sie einen Mac verwenden, verfügt Git über einen „osxkeychain“-Modus, der die Anmeldeinformationen im sicheren Schlüsselbund, der an Ihr Systemkonto angehängt ist, zwischenspeichert.

book/07-git-tools/sections/interactive-staging.asc

@@ -22,7 +22,7 @@ What now>
 ----
 
 Sie können erkennen, dass dieser Befehl Ihnen eine ganz neue Darstellung Ihrer Staging-Area zeigt, als Sie es gewohnt sind – im Grunde genommen zeigt sie die gleichen Informationen, die Sie mit `git status` erhalten, aber etwas kompakter und informativer.
-Es listet auf linken Seite die gestagten und auf der rechten Seite die nicht gestagten Änderungen auf.
+Es listet auf der linken Seite die gestagten und auf der rechten Seite die nicht gestagten Änderungen auf.
 
 Danach folgt der Bereich „Commands“ (Befehle), in dem Sie eine Reihe von Aktionen ausführen können, wie z.B. Staging und Unstaging von Dateien, Staging von Teilen von Dateien, Hinzufügen von nicht getrackten Dateien und das Anzeigen von Diffs (Unterschieden) der zuvor gestagten Dateien.
 
@@ -140,7 +140,7 @@ Mit diesen grundlegenden Befehlen können Sie den interaktiven Einfügen-Modus n
 Es ist auch möglich, dass Git nur bestimmte _Teile_ der Dateien stagt, ohne die restlichen Teile.
 Wenn Sie beispielsweise zwei Änderungen an Ihrer Datei `simplegit.rb` vornehmen und eine davon stagen möchten und die andere nicht, so ist das in Git sehr einfach.
 Geben Sie auf der gleichen interaktiven Eingabeaufforderung, die im vorherigen Abschnitt erläutert wurde, `p` oder `5` (für Patch) ein.
-Git wird Sie fragen, welche Dateien Sie teilweise stagen möchten; dann zeigt es für jeden Abschnitt der ausgewählten Dateien Diffs an und fragt Sie nacheinander,Stück für Stück, was Sie stagen möchten:
+Git wird Sie fragen, welche Dateien Sie teilweise stagen möchten; dann zeigt es für jeden Abschnitt der ausgewählten Dateien Diffs an und fragt Sie nacheinander, Stück für Stück, was Sie stagen möchten:
 
 [source,console]
 ----

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

@@ -123,7 +123,7 @@ Als nächstes führen wir `git add` aus, um sie in unseren Index zu übernehmen,
 
 image::images/reset-ex5.png[]
 
-Wenn wir zu diesem Zeitpunkt `git status` starten, sehen wir die Datei in grün unter „Changes to be committed“ (dt. Änderungen zum Commit vorgemerkt), weil sich der Index und der HEAD unterscheiden – d.h. unser geplanter nächster Commit unterscheidet sich nun von unserem letzten Commit.
+Wenn wir zu diesem Zeitpunkt `git status` ausführen, sehen wir die Datei in grün unter „Changes to be committed“ (dt. Änderungen zum Commit vorgemerkt), weil sich der Index und der HEAD unterscheiden – d.h. unser geplanter nächster Commit unterscheidet sich nun von unserem letzten Commit.
 Schließlich führen wir `git commit` aus, um die Daten zu übertragen.
 
 image::images/reset-ex6.png[]
@@ -171,14 +171,14 @@ Als nächstes wird `reset` den Index mit dem Inhalt des Schnappschusses aktualis
 image::images/reset-mixed.png[]
 
 Wenn Sie die Option `--mixed` angeben, wird `reset` an dieser Stelle beendet.
-Das ist auch die Voreinstellung, wenn Sie also überhaupt keine Option angeben (in diesem Fall nur `git reset HEAD~`), wird der Befehl an dort enden.
+Das ist auch die Voreinstellung, wenn Sie also überhaupt keine Option angeben (in diesem Fall nur `git reset HEAD~`), wird der Befehl dort enden.
 
 Nehmen Sie sich noch eine Minute Zeit, um sich jetzt diese Abbildung anzuschauen und zu erkennen, was passiert ist: Es hat Ihren letzten `commit` rückgängig gemacht, aber auch alles auf _unstaged_ gesetzt.
 Sie wurden auf den Stand zurück versetzt, bevor Sie alle Ihre `git add` und `git commit` Befehle ausgeführt hatten.
 
 ===== Step 3: Das Working Directory (Arbeitsverzeichnis) aktualisieren (--hard)
 
-Als Drittes wird das Arbeitsverzeichnis durch das `reset` zurückgesetzt, damit es dem Index entspricht.
+Als Drittes wird das Arbeitsverzeichnis durch `reset` zurückgesetzt, damit es dem Index entspricht.
 Wenn Sie die Option `--hard` verwenden, wird es bis zu diesem Schritt fortgesetzt.
 
 image::images/reset-hard.png[]

book/07-git-tools/sections/revision-selection.asc

@@ -355,7 +355,7 @@ Das sorgt für ein sehr leistungsfähiges Revisions-Abfragesystem, das Ihnen dab
 [[_triple_dot]]
 ===== Dreifacher  Punkt
 
-Die letzte wichtige Syntax für die Bereichsauswahl ist die Triple-Dot-Syntax (Dreifach-Punkt-Syntax), die alle Commits angibt, die durch _eine_ der beiden Referenzen erreichbar sind, aber nicht durch beide.
+Die letzte wichtige Syntax für die Bereichsauswahl ist die Dreifach-Punkt-Syntax (engl. Triple-Dot-Syntax), die alle Commits angibt, die durch _eine_ der beiden Referenzen erreichbar sind, aber nicht durch beide.
 Schauen Sie sich dazu die Commit-Historie in <<double_dot>> an.
 Wenn Sie wissen wollen, was sich in `master` oder `experiment` befindet, aber nicht in gemeinsamen Referenzen, können Sie diese Funktion ausführen:
 
@@ -370,7 +370,7 @@ C
 
 Auch hier erhalten Sie eine normale `log` Ausgabe. Es werden Ihnen jedoch nur die Commit-Informationen für diese vier Commits angezeigt, die in der traditionellen Reihenfolge der Commit-Daten erscheinen.
 
-Ein gängiger Parameter, der in hier mit dem `log` Befehl verwendet werden kann ist `--left-right`. Er zeigt Ihnen, auf welcher Seite des Bereichs sich der Commit gerade befindet.
+Ein gängiger Parameter, der hier mit dem `log` Befehl verwendet werden kann ist `--left-right`. Er zeigt Ihnen, auf welcher Seite des Bereichs sich der Commit gerade befindet.
 Auf diese Weise wird die Ausgabe besser auswertbar:
 
 [source,console]

book/07-git-tools/sections/rewriting-history.asc

@@ -157,7 +157,7 @@ Schreiben Sie
 $ git commit --amend
 ----
 
-Ändern Sie die Commit-Beschreibung und verlassen Sie den Editor.
+ändern Sie die Commit-Beschreibung und verlassen Sie den Editor.
 Dann rufen Sie folgenden Befehl auf:
 
 [source,console]

book/07-git-tools/sections/stashing-cleaning.asc

@@ -228,7 +228,7 @@ Das ist ein interessanter Weg, mit dem man die gestashten Arbeiten leicht wieder
 
 Letztendlich möchten Sie vielleicht einige Arbeiten oder Dateien nicht in Ihrem Arbeitsverzeichnis ablegen, sondern sie einfach nur loswerden; dafür ist der Befehl `git clean` gedacht.
 
-Einige gängige Fälle, in denen Sie Ihr Arbeitsverzeichnis bereinigen müssen, sind das Entfernen von überflüssigem Programmkode, der durch Merges oder externe Tools erzeugt wurde oder das Entfernen von Build-Artefakten, um einen sauberen Aufbau zu ermöglichen.
+Einige gängige Fälle, in denen Sie Ihr Arbeitsverzeichnis bereinigen müssen, sind das Entfernen von überflüssigem Programmcode, der durch Merges oder externe Tools erzeugt wurde oder das Entfernen von Build-Artefakten, um einen sauberen Aufbau zu ermöglichen.
 
 Sie sollten mit diesem Befehl sehr vorsichtig sein, da er darauf ausgelegt ist, Dateien aus Ihrem Arbeitsverzeichnis zu entfernen, die nicht getrackt werden.
 Wenn Sie Ihre Absicht ändern, gibt es oft keine Möglichkeit mehr, den Inhalt dieser Dateien wiederherzustellen.

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

@@ -644,7 +644,7 @@ Sollten die Historien der Submodule divergieren und Sie dorthin zu einem Hauptpr
 Ist einer der Commits ein direkter Vorfahre des anderen (ein fast-forward Merge), dann wählt Git einfach den letzteren für den Merge aus, so dass das gut funktioniert.
 
 Git wird nicht einmal einen trivialen Merge versuchen.
-Wenn die Submodule divergieren und gemergt werden müssen, erhalten Sie etwas, erhalten Sie ähnliche Informationen:
+Wenn die Submodule Commits divergieren und gemergt werden müssen, erhalten Sie ähnliche Informationen wie diese:
 
 [source,console]
 ----
@@ -683,8 +683,8 @@ In diesem Fall ist `eb41d76` der Commit in unserem Submodul, den *wir* hatten, u
 Wenn wir in unser Submodul-Verzeichnis gehen, sollte es bereits `eb41d76` enthalten, da es durch den Merge nicht angetastet wurde.
 Sollte das aus irgendeinem Grund nicht der Fall sein, können Sie einfach einen neuen Branch erstellen und auschecken, der auf dieses Verzeichnis zeigt.
 
-Wichtig ist der SHA-1 des Commit von der Gegenseite.
-Das müssen Sie einmischen und auflösen.
+Wichtig ist der SHA-1 des Commits von der Gegenseite.
+Das werden Sie mergen und lösen müssen.
 Sie können entweder direkt versuchen, den Merge mit dem SHA-1 durchzuführen oder Sie können einen Branch dafür erstellen und dann versuchen, diesen zu verschmelzen.
 Wir empfehlen letzteres – und sei es nur, um eine bessere Merge-Commit-Meldung zu erhalten.
 
@@ -786,7 +786,7 @@ Damit wird dasselbe erreicht, aber zumindest können Sie auf diese Weise überpr
 
 ==== Tipps für Submodule
 
-There are a few things you can do to make working with submodules a little easier.
+Es gibt ein paar Dinge, die Sie tun können, um sich die Arbeit mit den Untermodulen ein wenig zu erleichtern.
 
 ===== Submodul Foreach
 
@@ -1008,8 +1008,8 @@ Unpacking objects: 100% (11/11), done.
 Checking connectivity... done.
 ----
 
-Nehmen wir jetzt an, Sie hätten das in einer Branch getan.
-Wenn Sie versuchen, wieder zu einer Branch zu wechseln, in der sich diese Dateien noch im aktuellen Verzeichnisbaum und nicht in einem Submodul befinden, erhalten Sie diesen Fehler:
+Nehmen wir jetzt an, Sie hätten das in einem Branch getan.
+Wenn Sie versuchen, wieder zu einem Branch zu wechseln, in der sich diese Dateien noch im aktuellen Verzeichnisbaum und nicht in einem Submodul befinden, erhalten Sie diesen Fehler:
 
 [source,console]
 ----

book/07-git-tools/sections/subtree-merges.asc

@@ -80,7 +80,7 @@ Automatic merge went well; stopped before committing as requested
 ----
 
 Alle Änderungen aus dem Rack-Projekt werden in das Projekt gemergt und können lokal committet werden.
-Sie können auch das Gegenteil tun – Änderungen im Unterverzeichnis `rack` Ihres `master`-Branchss vornehmen und sie dann später in Ihren Branch `rack_branch` mergen, um sie den Autoren zu übermitteln oder sie zum Upstream zu pushen.
+Sie können auch das Gegenteil tun – Änderungen im Unterverzeichnis `rack` Ihres `master`-Branchs vornehmen und sie dann später in Ihren Branch `rack_branch` mergen, um sie den Autoren zu übermitteln oder sie zum Upstream zu pushen.
 
 Dadurch haben wir einen Workflow, der dem Submodul-Workflow ähnelt, ohne Submodule zu verwenden (das wir in <<ch07-git-tools#_git_submodules>> behandeln werden).
 Wir können Branches mit anderen verwandten Projekten in unserem Repository vorhalten und sie gelegentlich in unserem Projekt verschmelzen.