Vom sie zum du für Kapitel 3 (#374)

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

@@ -13,13 +13,13 @@ Wenn du ein Repository zum ersten Mal klonst, sind alle Dateien versioniert und
 Sobald du anfängst versionierte Dateien zu bearbeiten, erkennt Git diese als modifiziert, weil sie sich im Vergleich zum letzten Commit verändert haben.
 Die geänderten Dateien kannst du dann für den nächsten Commit vormerken und schließlich alle Änderungen, die sich in der Staging-Area befinden, einchecken (engl. committen). Danach wiederholt sich dieser Vorgang.
 
-.Der Status Ihrer Dateien im Überblick
-image::images/lifecycle.png[Der Status Ihrer Dateien im Überblick]
+.Der Status deiner Dateien im Überblick
+image::images/lifecycle.png[Der Status deiner Dateien im Überblick]
 
 [[_checking_status]]
 ==== Zustand von Dateien prüfen
 
-Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich Ihre Dateien gerade befinden, ist der Befehl `git status`.(((Git Befehle, status)))
+Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich deine Dateien gerade befinden, ist der Befehl `git status`.(((Git Befehle, status)))
 Wenn du diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern:
 
 [source,console]
@@ -210,7 +210,7 @@ Das `Rakefile` wurde modifiziert, staged und dann wieder modifiziert, so dass es
 ==== Ignorieren von Dateien
 
 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.
+Dazu gehören in der Regel automatisch generierte Dateien, wie Log-Dateien oder Dateien, die von deinem Build-System erzeugt werden.
 In solchen Fällen kannst du die Datei `.gitignore` erstellen, die eine Liste mit Vergleichsmustern enthält.(((ignorieren von Dateien)))(((Dateien, ignorieren)))
 Hier ist eine `.gitignore` Beispieldatei:
 
@@ -325,7 +325,7 @@ index 8ebb991..643e24f 100644
  that highlights your work in progress (and note in the PR title that it's
 ----
 
-Dieses Kommando vergleicht, was sich in Ihrem Arbeitsverzeichnis befindet, mit dem, was sich in Ihrer Staging-Area befindet.
+Dieses Kommando vergleicht, was sich in deinem Arbeitsverzeichnis befindet, mit dem, was sich in deiner Staging-Area befindet.
 Das Ergebnis gibt dir an, welche Änderungen du vorgenommen hast, die noch nicht gestaged sind.
 
 Wenn du wissen willst, was du zum Commit vorgemerkt hast, das in deinem nächsten Commit einfließt, kannst du `git diff --staged` verwenden.
@@ -343,7 +343,7 @@ index 0000000..03902a1
 +My Project
 ----
 
-Es ist wichtig zu wissen, dass `git diff` von sich aus nicht alle Änderungen seit Ihrem letzten Commit anzeigt – nur die Änderungen, die noch „unstaged“ sind.
+Es ist wichtig zu wissen, dass `git diff` von sich aus nicht alle Änderungen seit deinem letzten Commit anzeigt – nur die Änderungen, die noch „unstaged“ sind.
 Wenn du alle deine Änderungen bereits „gestaged“ hast, wird `git diff` dir keine Antwort geben.
 
 Ein weiteres Beispiel: Wenn du die Datei `CONTRIBUTING.md` stagst und dann bearbeitest, kannst du `git diff` verwenden, um die Änderungen in der Datei anzuzeigen, die staged und nicht staged sind.
@@ -515,7 +515,7 @@ Das ist bequem. Aber sei vorsichtig, manchmal führt dieses Flag dazu, dass du u
 ==== Dateien löschen
 
 (((Dateien, entfernen)))
-Um eine Datei aus Git zu entfernen, musst du sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen.
+Um eine Datei aus Git zu entfernen, musst du sie aus der Versionsverwaltung entfernen (genauer gesagt, aus deinem Staging-Bereich löschen) und dann committen.
 Der Befehl `git rm` erledigt das und entfernt die Datei auch aus deinem Arbeitsverzeichnis, so dass du sie beim nächsten Mal nicht mehr als „untracked“-Datei siehst.
 
 Wenn du die Datei einfach aus deinem Arbeitsverzeichnis entfernst, erscheint sie unter dem „Changes not staged for commit“-Bereich (das ist die _unstaged_-Area) deiner `git status` Ausgabe:
@@ -554,7 +554,7 @@ Wenn du das nächste Mal einen Commit ausführst, ist die Datei weg und ist nich
 Wenn du die Datei geändert oder bereits zur Staging-Area hinzugefügt hast, musst du das Entfernen mit der Option `-f` erzwingen.
 Hierbei handelt es sich um eine Sicherheitsfunktion, die ein versehentliches Entfernen von Dateien verhindert, die noch nicht in einem Snapshot aufgezeichnet wurden und die nicht von Git wiederhergestellt werden können.
 
-Eine weitere nützliche Sache, die du möglicherweise nutzen möchtest, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus deiner Staging-Area zu entfernen.
+Eine weitere nützliche Sache, die du möglicherweise nutzen möchtest, ist, die Datei in deinem Verzeichnisbaum zu behalten, sie aber aus deiner Staging-Area zu entfernen.
 Mit anderen Worten, du kannst die Datei auf deiner Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen.
 
 Das ist besonders dann nützlich, wenn du vergessen hast, etwas zu deiner Datei `.gitignore` hinzuzufügen und dies dann versehentlich gestaged hast (eine große Logdatei z.B. oder eine Reihe von .a-kompilierten Dateien).

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

@@ -2,14 +2,14 @@
 === Mit Remotes arbeiten
 
 Um an Git-Projekte mitarbeiten zu können, musst du wissen, wie du deine Remote-Repositorys verwalten kannst.
-Remote-Repositorys sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden.
+Remote-Repositorys sind Versionen deines Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden.
 Du kannst Mehrere davon haben, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar ist.
 Die Zusammenarbeit mit Anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn du deine Arbeit teilen möchtest.
 Die Verwaltung von Remote-Repositorys umfasst das Wissen, wie man entfernte Repositorys hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr.
 In diesem Abschnitt werden wir einige dieser Remote-Management-Fertigkeiten erörtern.
 
 [NOTE]
-.Remote-Repositorys können auch auf Ihrem lokalen Rechner liegen.
+.Remote-Repositorys können auch auf deinem lokalen Rechner liegen.
 ====
 Es ist durchaus möglich, dass du mit einem „entfernten“ Repository arbeiten kannst, das sich eigentlich auf demselben Host befindet auf dem du gerade arbeitest.
 Das Wort „remote“ bedeutet nicht unbedingt, dass sich das Repository an einem anderen Ort im Netzwerk oder Internet befindet, sondern nur, dass es an einem anderen Ort liegt.
@@ -106,7 +106,7 @@ Pauls `master` Branch ist nun lokal als `pb/master` erreichbar – Du kannst ihn
 Wir werden in <<ch03-git-branching#ch03-git-branching,Git Branching>> detailliert beschreiben, was Branches sind und wie man sie nutzt.
 
 [[_fetching_and_pulling]]
-==== Fetchen und Pullen von Ihren Remotes
+==== Fetchen und Pullen deiner Remotes
 
 Wie du gerade gesehen hast, kannst du Daten aus deinem Remote-Projekt abrufen:(((Git Befehle, fetch)))
 
@@ -124,7 +124,7 @@ Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in
 Du musst das Ganze manuell mit deiner Arbeit zusammenführen, wenn du soweit bist.
 
 Wenn dein aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), kannst du den Befehl `git pull` verwenden, um diesen entfernten Branch automatisch zu fetchen und dann mit deinem aktuellen Branch zu mergen (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 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 du geklont hast.
+Das könnte ein einfacherer oder komfortablerer Workflow sein. Standardmäßig richtet der Befehl `git clone` deinen 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 du geklont hast.
 Wenn du `git pull` ausführst, werden normalerweise Daten von dem Server abgerufen, von dem du ursprünglich geklont hast. Anschliessend wird automatisch versucht diese Daten in deinem Code zu mergen.
 
 [NOTE]
@@ -140,7 +140,7 @@ Wenn du jedoch mit dem Pullen einen Rebase machen willst:
 ====
 
 [[_pushing_remotes]]
-==== Zu Ihren Remotes Pushen
+==== Zu deinen Remotes Pushen
 
 Wenn du dein Projekt an einem Punkt hast, an dem du es teilen möchtest, können wir es zum Upstream verschieben (engl. pushen).
 Der Befehl dafür lautet: `git push <remote> <branch>`.(((Git Befehle, push)))

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

@@ -95,7 +95,7 @@ Die Datei `CONTRIBUTING.md` ist modifiziert und wieder im Status unstaged überf
 [NOTE]
 =====
 Es stimmt, dass `git reset` ein riskanter Befehl sein kann, besonders, wenn du das `--hard` Flag mitgibst.
-In dem oben beschriebenen Szenario wird die Datei in Ihrem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist.
+In dem oben beschriebenen Szenario wird die Datei in deinem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist.
 =====
 
 Im Moment ist dieser Aufruf alles, was du über den Befehl `git reset` wissen musst.