Fix spelling, chapter 6

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

@@ -5,7 +5,7 @@ Nun, da unser Konto eingerichtet ist, lassen Sie uns einige Details durchgehen,
 ==== Forken von Projekten
 
 (((Forken)))
-Wenn Sie zu einem bestehenden Projekt beitragen möchten, zu dem Sie keinen Push-Zugang haben, können Sie das Projekt „forken“.
+Wenn Sie zu einem bestehenden Projekt beitragen möchten, zu dem Sie keine Push-Berechtigungen haben, können Sie das Projekt „forken“.
 Wenn Sie ein Projekt „forken“, erstellt GitHub eine Kopie des Projekts, die ganz Ihnen gehört; es befindet sich in Ihrem Namensraum (engl. namespace), und Sie können Daten dorthin „hochladen“ (engl. push).
 
 [NOTE]
@@ -32,11 +32,11 @@ Nach ein paar Sekunden werden Sie auf Ihre neue Projektseite weitergeleitet, mit
 (((GitHub, Workflow)))
 GitHub ist auf einen bestimmten Collaboration-Workflow ausgerichtet, der sich auf Pull-Requests konzentriert.
 Dieser Ablauf funktioniert unabhängig davon, ob Sie eng in einem Team, in einem einzigen gemeinsamen Repository, mit einem global verteilten Unternehmen oder einem Netzwerk von Fremden, über Dutzende von Forks, zusammenarbeiten und zu einem Projekt beitragen.
-Es ist um den Workflow aus <<ch03-git-branching#_topic_branch,Themen-Branches>> konzentriert, der in Kapitel 3 <<ch03-git-branching#ch03-git-branching,Git Branching>> ausführlich besprochen wird.
+Es ist um den Workflow aus <<ch03-git-branching#_topic_branch,Themen-Branches>> konzentriert, der in Kapitel 3 <<ch03-git-branching#ch03-git-branching,Git Branching>> ausführlich besprochen wurde.
 
 Im Prinzip funktioniert der Ablauf so:
 
-1. Forken Sie das Projekt
+1. Forken Sie das Projekt.
 2. Erstellen Sie lokal einen Themen-Branch aus `master`.
 3. Machen Sie einige Commits, um das Projekt zu überarbeiten.
 4. Pushen Sie diesen Branch zu Ihrem GitHub-Projekt.
@@ -108,11 +108,11 @@ To https://github.com/tonychacon/blink
 ----
 
 <1> Wir klonen unsere Fork des Projekts lokal.
-<2> Wir erstellen einen Branch mit prägnantem Namen
-<3> Wir nehmen unsere Anpassung am Code vor
-<4> Wir überprüfen, ob die Änderung gut ist
-<5> Wir übernehmen (engl. commit) unsere Änderung in den Themen-Branch
-<6> Wir pushen Sie unseren neuen Themen-Branch zurück zu unserer GitHub-Fork
+<2> Wir erstellen einen Branch mit prägnantem Namen.
+<3> Wir nehmen unsere Anpassung am Code vor.
+<4> Wir überprüfen, ob die Änderung gut ist.
+<5> Wir übernehmen (engl. commit) unsere Änderung in den Themen-Branch.
+<6> Wir pushen unseren neuen Themen-Branch zurück zu unserer GitHub-Fork.
 
 Wenn wir nun zu unserem Fork auf GitHub zurückkehren, können wir sehen, dass GitHub bemerkt hat, dass wir einen neuen Themenzweig gepusht haben und zeigt uns einen großen grünen Button, um unsere Änderungen zu überprüfen und einen Pull Request zum ursprünglichen Projekt zu öffnen.
 
@@ -270,11 +270,11 @@ To https://github.com/tonychacon/blink
    ef4725c..3c8d735  slower-blink -> slow-blink
 ----
 
-<1> Das Original-Repository als Remote mit der Bezeichnung „upstream“ hinzufügen
-<2> Die neueste Arbeit von diesem Remote abrufen (engl. fetch)
+<1> Das Original-Repository als Remote mit der Bezeichnung „upstream“ hinzufügen.
+<2> Die neueste Arbeit von diesem Remote abrufen (engl. fetch).
 <3> Den Haupt-Branch dieses Repositorys mit dem Themen-Branch mergen.
-<4> Den aufgetretenen Konflikt beheben
-<5> Zum gleichen Themen-Branch zurück pushen
+<4> Den aufgetretenen Konflikt beheben.
+<5> Zum gleichen Themen-Branch zurück pushen.
 
 Sobald Sie das getan haben, wird der Pull-Request automatisch aktualisiert und erneut überprüft, um festzustellen, ob er sauber zusammengeführt werden kann.
 
@@ -309,7 +309,7 @@ Wir können die Beschreibung wie bei <<_pr_references>> eingeben.
 .Querverweise in einem Pull-Request
 image::images/mentions-01-syntax.png[PR references]
 
-Wenn wir diese Pull-Anfrage einreichen, werden wir sehen, dass alles wie in „<<_pr_references_render>>“ dargestellt wird..
+Wenn wir diese Pull-Anfrage einreichen, werden wir sehen, dass alles wie in „<<_pr_references_render>>“ dargestellt wird.
 
 [[_pr_references_render]]
 .Querverweise, die in einem Pull-Request erzeugt wurden
@@ -366,7 +366,7 @@ Wenn wir das in die Beschreibung unseres Pull Request oder Issue aufnehmen, sehe
 image::images/markdown-02-tasks.png[Example Task List]
 
 Diese Funktion wird häufig in Pull Requests verwendet, um zu verdeutlichen, was alles Sie auf dem Branch erledigen möchten, bevor der Pull Request bereit für die Zusammenführung ist.
-Der wirklich coole Teil ist, dass Sie einfach auf die Kontrollkästchen klicken können, um den Kommentar zu aktualisieren – Sie müssen den Markdown nicht direkt bearbeiten, um Aufgaben abzuwählen.
+Der wirklich coole Teil ist, dass Sie einfach auf die Kontrollkästchen klicken können, um den Kommentar zu aktualisieren – Sie müssen den Markdown nicht direkt bearbeiten, um Aufgaben als erledigt zu markieren.
 
 Darüber hinaus sucht GitHub nach Aufgabenlisten in Ihren Issues und Pull Requests und sie als Metadaten auf den aufgelisteten Seiten anzeigt.
 Wenn Sie z.B. einen Pull-Request mit Aufgabenliste haben und sich die Übersichtsseite aller Pull-Requests ansehen, können Sie sehen, wie weit er abgearbeitet ist.
@@ -429,7 +429,7 @@ image::images/markdown-05-quote.png[Rendered quoting]
 ===== Emojis
 
 Abschließend, Sie können auch Emojis in Ihren Kommentaren verwenden.
-Das wird in der Praxis sehr häufig in Kommentaren verwendet, die Sie es bei vielen GitHub-Issues und Pull-Requests sehen.
+Das wird in der Praxis sehr häufig in Kommentaren verwendet. Sie werden es in vielen GitHub-Issues und Pull-Requests sehen.
 Es gibt sogar einen Emoji-Helfer in GitHub.
 Wenn Sie einen Kommentar eingeben und mit einem `:` (Doppelpunkt) beginnen, hilft Ihnen ein Autokomplettierer, das Gesuchte schnell zu finden.
 
@@ -504,11 +504,11 @@ $ 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 ein lästig, die Fetch-URL jedes Mal neu eingeben zu müssen.
+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:
 
 [source,console]
@@ -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.

ch06-github.asc

@@ -14,8 +14,8 @@ Wenn Sie nicht daran interessiert sind, GitHub zu verwenden, um Ihre eigenen Pro
 [WARNING]
 .Schnittstellen Änderung
 ====
-Es ist wichtig zu beachten, dass sich die Oberflächenelemente in diesen Screenshots, wie bei vielen aktiven Websites, mit der Zeit ändern können.
-Hoffentlich wird die generelle Idee von dem was wir hier zu zeigen versuchen, immer noch sehen sein, aber wenn Sie aktuellere Versionen dieser Bildschirm-Darstellungen wollen, können die Online-Versionen dieses Buches aktuellere Screenshots enthalten.
+Es ist wichtig zu beachten, dass sich die Weboberfläche in diesen Screenshots, wie bei vielen aktiven Websites, sich mit der Zeit ändern können.
+Hoffentlich wird die generelle Idee von dem was wir hier zu zeigen versuchen, immer noch verständlich sein. Wenn Sie neuere Versionen der Weboberfläche benötigen, könnten die Online-Versionen diese Buchse aktuellere Screenshots enthalten.
 ====
 
 include::book/06-github/sections/1-setting-up-account.asc[]