spelling fixes (contributing/maintaining/managing)

Author: saxc

book/06-github/sections/2-contributing.asc

@@ -504,9 +504,9 @@ $ git pull https://github.com/progit/progit2.git <2>
 $ git push origin master <3>
 ----
 
-<1> Wenn Sie sich in einem anderen Branch befinden, kehren Sie zu `master` zurück.
-<2> Holen (engl. fetch) Sie sich Änderungen von `https://github.com/progit/progit2.git` und mergen Sie sie in den `master`.
-<3> Pushen Sie Ihren `master` Branch nach `origin`.
+<1> Wenn Sie sich in einem anderen Branch befinden, kehren Sie zu `master` zurück
+<2> Holen (engl. fetch) Sie sich Änderungen von `https://github.com/progit/progit2.git` und mergen Sie sie in den `master`
+<3> Pushen Sie Ihren `master` Branch nach `origin`
 
 Das funktioniert, aber es ist lästig, die Fetch-URL jedes Mal neu eingeben zu müssen.
 Sie können diese Arbeit mit ein wenig Konfiguration automatisieren:
@@ -518,10 +518,10 @@ $ git branch --set-upstream-to=progit/master master <2>
 $ git config --local remote.pushDefault origin <3>
 ----
 
-<1> Fügen Sie das Quell-Repository hinzu und geben Sie ihm einen Namen.
-Hier habe ich mich entschieden, es `progit` zu nennen.
-<2> Konfigurieren Sie Ihren `master` Branch so, dass er von dem `progit` Remote abgeholt (engl. fetch) wird.
-<3> Definieren Sie das standardmäßige Push-Repository auf `origin`.
+<1> Fügen Sie das Quell-Repository hinzu und geben Sie ihm einen Namen
+Hier habe ich mich entschieden, es `progit` zu nennen
+<2> Konfigurieren Sie Ihren `master` Branch so, dass er von dem `progit` Remote abgeholt (engl. fetch) wird
+<3> Definieren Sie das standardmäßige Push-Repository auf `origin`
 
 Sobald das getan ist, wird der Workflow viel einfacher:
 
@@ -532,9 +532,9 @@ $ git pull <2>
 $ git push <3>
 ----
 
-<1> Wenn Sie sich in einem anderen Branch befinden, kehren Sie zu `master` zurück.
-<2> Fetchen Sie die Änderungen von `progit` und mergen Sie sie in `master`.
-<3> Pushen Sie Ihren `master` Branch nach `origin`.
+<1> Wenn Sie sich in einem anderen Branch befinden, kehren Sie zu `master` zurück
+<2> Fetchen Sie die Änderungen von `progit` und mergen Sie sie in `master`
+<3> Pushen Sie Ihren `master` Branch nach `origin`
 
 Dieser Herangehensweise kann nützlich sein, aber sie ist nicht ohne Nachteile.
 Git wird diese Aufgabe gerne im Hintergrund für Sie erledigen, aber es wird Sie nicht benachrichtigen, wenn Sie einen Commit zum `master` machen, von `progit` pullen und dann zu `origin` pushen – alle diese Operationen sind mit diesem Setup zulässig.

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

@@ -166,7 +166,7 @@ Git folgt gern und lädt alles herunter, was Sie brauchen, um diesen Ref zu erst
 Sie können das mit `git merge FETCH_HEAD` in einen Branch fortsetzen. In diesem wollen Sie testen, aber die Merge-Commit-Nachricht sieht ein wenig merkwürdig aus.
 Wenn Sie *viele* Pull-Requests überprüfen müssen, wird das umständlich.
 
-Es gibt auch eine Möglichkeit wie Sie _alle_ Pull-Requests abrufen und aktuell zu halten können, wann immer Sie sich mit dem Remote verbinden.
+Es gibt auch eine Möglichkeit wie Sie _alle_ Pull-Requests abrufen und aktuell halten können, wann immer Sie sich mit dem Remote verbinden.
 Öffnen Sie `.git/config` in Ihrem bevorzugten Editor und suchen Sie nach dem `origin` Remote.
 Es sollte ein bißchen wie folgt aussehen:
 
@@ -191,7 +191,7 @@ Sie können diesen Teil ändern, um eine weitere Referenz (refspec) hinzuzufüge
 ----
 
 Diese letzte Zeile meldet Git: „Alle Referenzen, die wie `refs/pull/123/head` aussehen, sollten lokal als `refs/remotes/origin/pr/123` gespeichert werden.“
-Wenn Sie jetzt diese Datei speichern und ein `git fetch` auslösen, passiert folgendes:
+Wenn Sie jetzt diese Datei speichern und ein `git fetch` ausführen, passiert folgendes:
 
 [source,console]
 ----

book/06-github/sections/4-managing-organization.asc

@@ -21,7 +21,7 @@ Befolgen Sie diese Anweisungen und Sie werden bald Eigentümer einer brandneuen
 Wie persönliche Konten sind Unternehmen kostenlos, wenn alles, was Sie dort ablegen wollen, Open Source sein wird.
 
 Als Eigentümer in einer Organisation haben Sie beim Forken eines Repository die Wahl, es in den Namensraum Ihrer Organisation zu übertragen.
-Wenn Sie neue Repositories erstellen, können Sie diese entweder unter Ihrem persönlichen Konto oder unter dem einer der Organisationen erstellen, deren Sie Eigentümer sind.
+Wenn Sie neue Repositories erstellen, können Sie diese entweder unter Ihrem persönlichen Konto oder unter dem einer der Organisationen erstellen, deren Eigentümer Sie sind.
 Sie „beobachten“ (engl. watch) auch automatisch jedes neue Repository, das unter diesen Unternehmen erstellt wird.
 
 Wie in <<_personal_avatar,Ihr Avatar-Bild>> gezeigt, können Sie ein Symbol-Bild für Ihre Organisation hochladen, um sie ein wenig zu personalisieren.