Vervollständige Umstellung von formeller "Sie"-Form auf informelle "Du"-Form

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

@@ -7,7 +7,7 @@ Sei vorsichtig, man kann diese Aktionen nicht immer rückgängig machen.
 Das ist einer der wenigen Bereiche in Git, in denen du Arbeit verlieren könntest, wenn du etwas falsch machst.
 
 Eines der häufigsten Undos tritt auf, wenn du zu früh committest und möglicherweise vergessen hast, einige Dateien hinzuzufügen, oder wenn du Fehler in deiner Commit-Nachricht hast.
-Wenn du diesen Commit wiederholen möchtest, nimm zusätzlichen Änderungen vor, die du vergessen hast, stage Sie und committe erneut mit der Option `--amend`:
+Wenn du diesen Commit wiederholen möchtest, nimm zusätzlichen Änderungen vor, die du vergessen hast, stage sie und committe erneut mit der Option `--amend`:
 
 [source,console]
 ----

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

@@ -10,8 +10,8 @@ Da Git ein einfaches 3-Wege-Merge verwendet, ist mehrmaliges Zusammenführen von
 Das bedeutet, du kannst mehrere Branches haben, die immer offen sind und die du für unterschiedliche Stadien deines Entwicklungszyklus verwendest; du kannst sie regelmäßig mit anderen zusammenführen.
 
 Viele Git-Entwickler folgen einem Workflow, welcher den Ansatz verfolgt, nur stabilen Code im `master` Branch zu haben – möglicherweise auch nur Code, der released wurde oder werden soll.
-Sie haben einen weiteren parallele Branches namens `develop` oder `next`, auf denen Sie arbeiten oder die Sie für Stabilitätstests nutzen. Diese sind nicht zwangsläufig stabil, aber wann immer sie einen stabilen Zustand erreichen, können sie mit dem `master` Branch zusammengeführt werden.
-Sie werden genutzt, um Features (kurzlebige Branches, wie der früher genutzte `iss53` Branch) einfließen zu lassen, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass sie alle Tests bestehen und keine Fehler einführen.
+Du hast einen weiteren parallelen Branch namens `develop` oder `next`, auf dem du arbeitest oder den du für Stabilitätstests nutzt. Dieser ist nicht zwangsläufig stabil, aber wann immer er einen stabilen Zustand erreicht, kann er mit dem `master` Branch zusammengeführt werden.
+Es werden Feature-Branches (kurzlebige Branches, wie der früher genutzte `iss53` Branch) eingebunden, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass sie alle Tests bestehen und keine Fehler einführen.
 
 Eigentlich reden wir gerade über Zeiger, die sich in der Reihe der Commits, die du durchführst, vorwärts bewegen.
 Die stabilen Branches sind weiter hinten und die allerneuesten Branches sind weiter vorn im Verlauf.
@@ -27,7 +27,7 @@ image::images/lr-branches-2.png[„Silo“-Modell eines Branchings mit zunehmend
 
 Du kannst das für mehrere Stabilitätsgrade einrichten.
 Einige größere Projekte haben auch einen Branch `proposed` (vorgeschlagen) oder `pu` (proposed updates – vorgeschlagene Updates), in welchem Branches integriert sind, die vielleicht noch nicht bereit sind in den Branch `next` oder `master` einzufließen.
-Die Idee dahinter ist, dass Ihre Branches verschiedene Stabilitäts-Level repräsentieren. Sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt.
+Die Idee dahinter ist, dass deine Branches verschiedene Stabilitäts-Level repräsentieren. Sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt.
 Zur Erinnerung: Langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich. Insbesondere dann, wenn man es mit sehr großen oder komplexen Projekten zu tun hat.
 
 [[_topic_branch]]

book/04-git-server/sections/git-on-a-server.asc

@@ -68,15 +68,15 @@ Du siehst, wie einfach es ist, aus einem Git-Repository eine leere Version zu er
 Jetzt seid ihr der Lage, am gleichen Projekt zusammenzuarbeiten.
 
 Das ist auch schon alles ist, was zu tun ist, um einen brauchbaren Git-Server zu betreiben, auf den mehrere Personen Zugriff haben. Füge einfach SSH-fähige Konten auf einem Server hinzu und lege ein leeres Repository an einen Ort, auf das alle diese Benutzer Lese- und Schreibrechte haben.
-Ihr seid nun startklar – mehr ist nicht nötig.
+Du bist nun startklar – mehr ist nicht nötig.
 
 In den nächsten Abschnitten erfährst du, wie du dieses Grundkonstrukt zu komplexeren Konfigurationen erweitern kannst.
 Das beinhaltet, dass man nicht für jeden Benutzer ein Benutzerkonto anlegen muss, öffentlichen Lesezugriff auf Repositorys hinzufügt und Web-UIs einrichtet und vieles mehr.
 Denke jedoch daran, dass zur Zusammenarbeit mit ein paar Personen bei einem privaten Projekt _nur_ ein SSH-Server und ein Bare-Repository benötigt wird.
 
 ==== Kleine Installationen
 
-Wenn Ihr ein kleines Team seid, die Git nur in einer kleinen Umgebung ausprobieren wollen und nur wenige Entwickler habt, kann es ganz einfach sein.
+Wenn du in einem kleinen Team bist, das Git nur in einer kleinen Umgebung ausprobieren will und nur wenige Entwickler hat, kann es ganz einfach sein.
 Einer der kompliziertesten Aspekte bei der Einrichtung eines Git-Servers ist die Benutzerverwaltung.
 Wenn du möchtest, dass einige Repositorys für bestimmte Benutzer schreibgeschützt und für andere lesend und schreibend sind, können Zugriff und Berechtigungen etwas schwieriger zu realisieren sein.
 

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

@@ -24,7 +24,7 @@ Als Eigentümer in einer Organisation hast du beim Forken eines Repository die W
 Wenn du neue Repositorys erstellst, kannst du diese entweder unter deinem persönlichen Konto oder unter dem einer der Organisationen erstellen, deren Eigentümer du bist.
 Du „beobachtest“ (engl. watch) auch automatisch jedes neue Repository, das unter diesen Unternehmen erstellt wird.
 
-Wie in <<_personal_avatar,Ihr Avatar-Bild>> gezeigt, kannst du ein Symbol-Bild für deine Organisation hochladen, um sie ein wenig zu personalisieren.
+Wie in <<_personal_avatar,Dein Avatar-Bild>> gezeigt, kannst du ein Symbol-Bild für deine Organisation hochladen, um sie ein wenig zu personalisieren.
 Wie bei persönlichen Konten hast du auch eine Startseite für die Organisation, die alle deine Repositorys auflistet und von anderen eingesehen werden kann.
 
 Lass uns jetzt einige der Punkte ansprechen, die mit einem Organisationskonto etwas anders sind.

book/08-customizing-git/sections/config.asc

@@ -134,7 +134,7 @@ Wenn du diese Konfiguration nutzt, wird Git die komplette Ausgabe aller Befehle
 ===== `user.signingkey`
 
 (((GPG)))
-Wenn du signierte und annotierte Tags erstellst (wie in Kapitel 7, <<ch07-git-tools#_signing,Ihre Arbeit signieren>> beschrieben), erleichtert die Definition deines GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit.
+Wenn du signierte und annotierte Tags erstellst (wie in Kapitel 7, <<ch07-git-tools#_signing,Deine Arbeit signieren>> beschrieben), erleichtert die Definition deines GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit.
 Stelle deine Schlüssel-ID so ein:
 
 [source,console]

book/B-embedding-git/sections/jgit.asc

@@ -146,7 +146,7 @@ for (Ref ref : remoteRefs) {
 
 Das ist ein typisches Muster mit der Git-Klasse. Die Methoden geben ein Befehlsobjekt zurück, mit dem du Methodenaufrufe verketten kannst, um Parameter zu setzen, die beim Aufruf von `.call()` ausgeführt werden.
 Hier befragen wir den `origin` Remote nach Tags, nicht nach Heads.
-Beachten Sie auch die Verwendung des Objekts `CredentialsProvider` zur Authentifizierung.
+Beachte auch die Verwendung des Objekts `CredentialsProvider` zur Authentifizierung.
 
 Viele andere Befehle sind über die Git-Klasse verfügbar, einschließlich, aber nicht beschränkt auf `add`, `blame`, `commit`, `clean`, `push`, `rebase`, `revert` und `reset`.
 

book/B-embedding-git/sections/libgit2.asc

@@ -53,7 +53,7 @@ Aus diesem Beispiel, wurden einige Pattern erstellt:
 
 (((Ruby)))
 Das letzte Argument kann bedeuten, dass du eventuell keinen C-Code schreiben wirst, wenn du Libgit2 verwendest.
-Glücklicherweise gibt es eine Reihe von sprachspezifischen Anbindungen, die es ziemlich einfach machen, mit Git-Repositorys in Ihrer spezifischen Programmier-Sprache und -Umgebung zu arbeiten.
+Glücklicherweise gibt es eine Reihe von sprachspezifischen Anbindungen, die es ziemlich einfach machen, mit Git-Repositorys in deiner spezifischen Programmier-Sprache und -Umgebung zu arbeiten.
 Schauen wir uns das obige Beispiel an, das mit den Ruby-Anbindungen für Libgit2 geschrieben wurde, die Rugged genannt werden und unter https://github.com/libgit2/rugged[^] zu finden sind.
 
 [source,ruby]
@@ -141,7 +141,7 @@ _Beachte, dass Fehler zwar erfasst, aber nicht bearbeitet werden. Wir hoffen, da
 <4> Ein Repository öffnen und so einrichten, dass es unsere ODB zum Suchen von Objekten verwendet.
 
 Aber was ist das für ein `git_odb_backend_mine`?
-Nun, das ist der Konstruktor für Ihre eigene ODB-Implementation. Du kannst dort machen, was immer du willst, solange du die `git_odb_backend` Struktur richtig eingibst.
+Nun, das ist der Konstruktor für deine eigene ODB-Implementation. Du kannst dort machen, was immer du willst, solange du die `git_odb_backend` Struktur richtig eingibst.
 Hier sieht man, wie es ausschauen _könnte_:
 
 [source,c]

book/introduction.asc

@@ -20,7 +20,7 @@ Hier erfährst du, was Git wirklich von der Masse abhebt.
 Wenn du das Kapitel zu Ende gebracht hast, wirst du vielleicht in einem ruhigen Moment darüber nachdenken, wie du bisher ohne Gits Branching hast Leben können (du wirst keine Antwort finden :-)).
 
 *Kapitel 4* befasst sich mit Git auf dem Server.
-Mit diesem Kapitel wenden wir uns an diejenigen von euch, die Git innerhalb Ihrer Organisation oder auf Ihrem eigenen persönlichen Server für die gemeinsame Entwicklung einrichten möchten.
+Mit diesem Kapitel wenden wir uns an diejenigen von euch, die Git innerhalb eurer Organisation oder auf eurem eigenen persönlichen Server für die gemeinsame Entwicklung einrichten möchten.
 Wir werden auch verschiedene Hosting-Optionen erörtern, falls du es vorziehst, dass jemand anderes diese Aufgabe für dich übernimmt.
 
 *Kapitel 5* geht ausführlich auf verschiedene dezentrale Workflows ein und wie man sie mit Git realisieren kann.

ch02-git-basics-chapter.asc

@@ -4,7 +4,7 @@
 Falls du es eilig hast und du nur die Zeit hast ein einziges Kapitel dieses hervorragendes Buches durchzulesen, bist du hier genau richtig. 
 
 Dieses Kapitel behandelt alle grundlegenden Befehle, die Du benötigst, um den großteil der Aufgaben zu erledigen, die mit Git erledigt werden müssen.
-Am Ende des Kapitels solltest Du in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. Sie aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und einen Commit durchzuführen.
+Am Ende des Kapitels solltest Du in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. sie aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und einen Commit durchzuführen.
 
 Außerdem wird gezeigt, wie Du Git so konfigurieren kannst, dass es bestimmte Dateien und Dateimuster ignoriert, wie Du Fehler schnell und einfach rückgängig machen, wie Du die Historie eines Projekts durchsuchen und Änderungen zwischen Commits nachschlagen, und wie Du von einem Remote-Repository Daten herunter- bzw. dort hochladen kannst.