Vervollständige Umstellung von formeller "Sie"-Form auf informelle "Du"-Form (#427)

* Initial plan

* Fix remaining formal 'Sie' form instances to informal 'Du'

Co-authored-by: pastatopf <6805462+pastatopf@users.noreply.github.com>

* Continue fixing formal 'Sie' to informal 'Du' in C-git-commands.asc

Co-authored-by: pastatopf <6805462+pastatopf@users.noreply.github.com>

* Complete conversion of formal 'Sie' to informal 'Du' in C-git-commands.asc

Co-authored-by: pastatopf <6805462+pastatopf@users.noreply.github.com>

* Update book/introduction.asc

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

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

* Apply suggestions from code review

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: pastatopf <6805462+pastatopf@users.noreply.github.com>

Author: Copilot

C-git-commands.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/02-git-basics/sections/undoing.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.
+Sie haben einen weiteren parallelen Branches namens `develop` oder `next`, auf denen Sie arbeiten oder den Sie für Stabilitätstests nutzen. Dieser ist nicht zwangsläufig stabil, aber wann immer er einen stabilen Zustand erreicht, kann er in dem `master` Branch gemerged werden.
+Er wird genutzt, um Features (kurzlebige Branches, wie der früher genutzte `iss53` Branch) einfließen zu lassen, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass er alle Tests besteht und keine Fehler einführt.
 
 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/03-git-branching/sections/workflows.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/06-github/sections/4-managing-organization.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/08-customizing-git/sections/config.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/jgit.asc

@@ -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/B-embedding-git/sections/libgit2.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.