Ch08 vom sie zum du (#387)

* Sie durch du ersetzt

* vom sie zum du

* vom sie zum du - next

Author: pastatopf

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

@@ -247,7 +247,7 @@ To /[email protected]:schacon/simplegit.git
  - [deleted]         v1.4-lw
 ----
 
-Zur Erklärung des obigen Befehls: Vor dem Doppelpunkt ist nichts und somit als Nullwert zu lesen. Darauf wird der Remote-Tag-Name gepushed, wodurch dieser gelöscht wird.
+Zur Erklärung des obigen Befehls: Vor dem Doppelpunkt ist nichts und somit als Nullwert zu lesen. Darauf wird der Remote-Tag-Name gepusht, wodurch dieser gelöscht wird.
 
 Der zweite, intuitivere Weg, ein Remote-Tag zu löschen, ist mit:
 

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

@@ -40,7 +40,7 @@ Standardmäßig, d.h. ohne Argumente, listet `git log` die in diesem Repository
 Wie du sehen kannst, listet dieser Befehl jeden Commit mit seiner SHA-1-Prüfsumme, dem Namen und der E-Mail-Adresse des Autors, dem Erstellungs-Datum und der Commit-Beschreibung auf.
 
 Eine Vielzahl von Optionen stehen für den Befehl `git log` zur Verfügung, um dir exakt das anzuzeigen, wonach du suchst.
-Hier zeigen wir Ihnen einige der gängigsten.
+Hier zeigen wir dir einige der gängigsten.
 
 Eine der hilfreichsten Optionen ist `-p` oder `--patch`. Sie zeigt die Änderungen (die _patch_-Ausgabe) an, die bei jedem Commit durchgeführt wurden.
 Du kannst auch die Anzahl der anzuzeigenden Protokolleinträge begrenzen, z.B. mit `-2` werden nur die letzten beiden Einträge dargestellt.

book/03-git-branching/sections/rebasing.asc

@@ -181,7 +181,7 @@ Man kann ziemlich sicher davon ausgehen, dass der andere Entwickler `C4` und `C6
 ==== Rebasen, wenn du Rebase durchführst
 
 Wenn du dich in einer solchen Situation *befindest*, hat Git eine weitere magische Funktion, die dir helfen könnte.
-Falls jemand in deinem Team forcierte Änderungen pushed, die Arbeiten überschreiben, auf denen deine basiert, besteht deine Herausforderung darin, herauszufinden, was dir gehört und was andere überschrieben haben.
+Falls jemand in deinem Team forcierte Änderungen pusht, die Arbeiten überschreiben, auf denen deine basiert, besteht deine Herausforderung darin, herauszufinden, was dir gehört und was andere überschrieben haben.
 
 Es stellt sich heraus, dass Git neben der SHA-1-Prüfsumme eine weitere Prüfsumme berechnet, die nur auf den mit dem Commit eingeführten Änderungen basiert.
 Diese wird „patch-id“ genannt.

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

@@ -124,7 +124,7 @@ Branch serverfix set up to track remote branch serverfix from origin.
 Switched to a new branch 'serverfix'
 ----
 
-Das erstellt Ihnen einen lokalen Branch, an dem du arbeiten kannst, und der dort beginnt, wo `origin/serverfix` derzeit steht.
+Das erstellt dir einen lokalen Branch, an dem du arbeiten kannst, und der dort beginnt, wo `origin/serverfix` derzeit steht.
 
 [[_tracking_branches]]
 ==== Tracking-Branches

book/05-distributed-git/sections/maintaining.asc

@@ -346,7 +346,7 @@ Wenn die Codebasis auf diesem Branch stabil ist und die Tests erfolgreich sind,
 Das Git-Projekt selber hat vier kontinuierlich laufende Branches: `master`, `next` und `seen` (vormals 'pu' – vorgeschlagene Updates) für neue Arbeiten und `maint` für Wartungs-Backports.
 Wenn neue Arbeiten von Mitwirkenden eingereicht werden, werden sie in ähnlicher Weise wie oben beschrieben in Featurebranches im Projektrepository des Betreuers gesammelt (siehe <<merwf_f>>).
 Zu diesem Zeitpunkt werden die Features evaluiert, um festzustellen, ob sie korrekt sind und zur Weiterverarbeitung bereit sind oder ob sie Nacharbeit benötigen.
-Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird dann gepushed, damit jeder die miteinander integrierten Features testen kann.
+Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird dann gepusht, damit jeder die miteinander integrierten Features testen kann.
 
 [[merwf_f]]
 .Verwaltung einer komplexen Reihe paralleler Featurebranches

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

@@ -233,7 +233,7 @@ image::images/pr-01-fail.png[PR merge Fehlschlag]
 Wenn du etwa „<<_pr_fail>>“ siehst, solltest du deinen Branch so reparieren, dass er grün wird und der Maintainer keine zusätzliche Arbeit leisten muss.
 
 Du hast grundsätzlich zwei Möglichkeiten, wie du das realisieren kannst.
-Du kannst deinen Branch entweder auf den Ziel-Branch rebasen (normalerweise den `master` Branch des von Ihnen geforkten Repositorys), oder du kannst den Ziel-Branch mit deinem Branch mergen.
+Du kannst deinen Branch entweder auf den Ziel-Branch rebasen (normalerweise den `master` Branch des von dir geforkten Repositorys), oder du kannst den Ziel-Branch mit deinem Branch mergen.
 
 Die meisten Entwickler auf GitHub werden sich aus den gleichen Gründen für Letzteres entscheiden, die wir im vorherigen Abschnitt erläutert haben.
 Was wichtig ist, ist die Verlaufskontrolle und der endgültige Merge, so dass das Rebasing nicht viel mehr bringt als eine etwas aufgeräumtere Historie. Im Gegenzug ist es *viel* schwieriger und fehleranfälliger.

book/06-github/sections/5-scripting.asc

@@ -227,7 +227,7 @@ Du kannst die API verwenden, um so ziemlich alles zu tun, was du auf der Website
 Ein abschließendes Beispiel werden wir uns ansehen, da es wirklich praktisch ist, wenn du mit Pull-Requests arbeitest.
 Jeder Übertragung können ein oder mehrere Zustände zugeordnet sein. Es gibt eine API für das Hinzufügen und Abfragen dieser Stati.
 
-Die meisten der Dienste für kontinuierliche Integration und Tests nutzen diese API, um auf Pushes zu reagieren, indem sie den Code testen, der gepushed wurde, und dann Bericht erstatten, wenn dieser Commit alle Tests bestanden hat.
+Die meisten der Dienste für kontinuierliche Integration und Tests nutzen diese API, um auf Pushes zu reagieren, indem sie den Code testen, der gepusht wurde, und dann Bericht erstatten, wenn dieser Commit alle Tests bestanden hat.
 Du kannst damit auch überprüfen, ob die Commit-Nachricht korrekt formatiert ist, ob der Einreicher alle deine Contributions-Richtlinien befolgt hat, ob die Übertragung gültig signiert wurde – und vieles mehr.
 
 Angenommen, du richtest einen Webhook in deinem Repository ein, der einen kleinen Webdienst aufruft, der in der Commit-Nachricht nach einer Zeichenkette `Signed-off-by` sucht.