Ch04 vom sie zum du (#378)

* Vom Siezen zum Duzen

* Weitere eingeduzte Dateien

book/01-introduction/sections/about-version-control.asc

@@ -43,7 +43,7 @@ Administratoren haben die Möglichkeit, detailliert festzulegen, wer was tun kan
 Allerdings hat dieser Aufbau auch einige erhebliche Nachteile.
 Der offensichtlichste Nachteil ist das Risiko eines Systemausfalls bei Ausfall einer einzelnen Komponente, d.h. wenn der zentrale Server ausfällt.
 Wenn dieser Server nur für eine Stunde nicht verfügbar ist, dann kann in dieser einen Stunde niemand in irgendeiner Form mit anderen zusammenarbeiten oder Dateien, an denen gerade gearbeitet wird, versioniert abspeichern.
-Wenn die auf dem zentralen Server eingesetzte Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner noch vorliegen haben.
+Wenn die auf dem zentralen Server eingesetzte Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitstreiter gerade zufällig auf ihrem Rechner noch vorliegen haben.
 Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: Wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle schief läuft.
 
 ==== Verteilte Versionsverwaltung

book/04-git-server/sections/generating-ssh-key.asc

@@ -3,11 +3,11 @@
 
 (((SSH Keys)))(((SSH Schlüssel)))
 Viele Git-Server authentifizieren sich über öffentliche SSH-Schlüssel.
-Um einen öffentlichen Schlüssel bereitzustellen, muss jeder Benutzer in Ihrem System selbst einen generieren, falls er noch keinen hat.
+Um einen öffentlichen Schlüssel bereitzustellen, muss jeder Benutzer in seinem System selbst einen generieren, falls er noch keinen hat.
 Der Ablauf ist für alle Betriebssysteme gleich.
-Zuerst sollten Sie überprüfen, ob Sie noch keinen Schlüssel haben.
+Zuerst solltest du überprüfen, ob du noch keinen Schlüssel hast.
 Standardmäßig werden die SSH-Schlüssel eines Benutzers im Verzeichnis `~/.ssh` dieses Benutzers gespeichert.
-Sie können leicht nachsehen, ob Sie bereits über einen Schlüssel verfügen, indem Sie in dieses Verzeichnis gehen und den Inhalt auflisten:
+Du kannst leicht nachsehen, ob du bereits über einen Schlüssel verfügst, indem du in dieses Verzeichnis gehst und den Inhalt auflistest:
 
 [source,console]
 ----
@@ -17,9 +17,9 @@ authorized_keys2  id_dsa       known_hosts
 config            id_dsa.pub
 ----
 
-Suchen Sie ein Datei-Paar mit dem Namen `id_dsa` oder `id_rsa` und eine entsprechende Datei mit der Erweiterung `.pub`.
-Die `.pub` Datei ist Ihr öffentlicher Schlüssel, und die andere Datei ist der zugehörige private Schlüssel.
-Wenn Sie diese Dateien nicht haben (oder nicht einmal ein `.ssh` Verzeichnis vorhanden ist), können Sie sie erstellen, indem Sie ein Programm namens `ssh-keygen` ausführen, das im SSH-Paket auf Linux/macOS-Systemen enthalten ist und mit Git für Windows installiert wird:
+Suche ein Datei-Paar mit dem Namen `id_dsa` oder `id_rsa` und eine entsprechende Datei mit der Erweiterung `.pub`.
+Die `.pub` Datei ist dein öffentlicher Schlüssel, und die andere Datei ist der zugehörige private Schlüssel.
+Wenn du diese Dateien nicht hast (oder nicht einmal ein `.ssh` Verzeichnis vorhanden ist), kannst du sie erstellen, indem du ein Programm namens `ssh-keygen` ausführst, das im SSH-Paket auf Linux/macOS-Systemen enthalten ist und mit Git für Windows installiert wird:
 
 [source,console]
 ----
@@ -35,11 +35,11 @@ The key fingerprint is:
 d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 [email protected]
 ----
 
-Zuerst wird der Speicherort des Schlüssels (`.ssh/id_rsa`) festgelegt, danach wird zweimal nach einer Passphrase gefragt, die Sie leer lassen können, wenn Sie beim Verwenden des Schlüssels kein Passwort eingeben möchten.
-Wenn Sie jedoch ein Passwort verwenden, fügen Sie die Option `-o` hinzu; sie speichert den privaten Schlüssel in einem Format, das resistenter gegen Brute-Force-Passwortcracking ist als das Standardformat.
-Sie können auch das `ssh-agent` Tool verwenden, um zu vermeiden, dass Sie das Passwort jedes Mal neu eingeben müssen.
+Zuerst wird der Speicherort des Schlüssels (`.ssh/id_rsa`) festgelegt, danach wird zweimal nach einer Passphrase gefragt, die du leer lassen kannst, wenn du beim Verwenden des Schlüssels nicht jedes mal ein Passwort eingeben möchtest.
+Wenn du jedoch ein Passwort verwendest, fügst du die Option `-o` hinzu; diese speichert den privaten Schlüssel in einem Format, das resistenter gegen Brute-Force-Passwortcracking ist als das Standardformat.
+Du kannst auch das `ssh-agent` Tool verwenden, um zu vermeiden, dass du das Passwort jedes Mal neu eingeben musst.
 
-Jetzt muss jeder Benutzer seinen öffentlichen Schlüssel an Sie oder an einen Administrator des Git-Servers senden (vorausgesetzt, Sie verwenden ein SSH-Server-Setup, für das öffentliche Schlüssel erforderlich sind).
+Jetzt muss jeder Benutzer seinen öffentlichen Schlüssel an dich oder an einen Administrator des Git-Servers senden (vorausgesetzt, du verwendest ein SSH-Server-Setup, für das öffentliche Schlüssel erforderlich sind).
 Alles, was man tun muss, ist, den Inhalt der `.pub` Datei zu kopieren und per E-Mail zu versenden.
 Die öffentlichen Schlüssel sehen in etwa so aus:
 
@@ -54,4 +54,4 @@ mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 NrRFi9wrf+M7Q== [email protected]
 ----
 
-Ein ausführliches Tutorial zur Erstellung eines SSH-Schlüssels für unterschiedliche Betriebssysteme finden Sie in der GitHub-Anleitung für SSH-Schlüssel unter https://docs.github.com/de/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent[Generieren und Hinzufügen eines SSH-Schlüssels^].
+Ein ausführliches Tutorial zur Erstellung eines SSH-Schlüssels für unterschiedliche Betriebssysteme findest du in der GitHub-Anleitung für SSH-Schlüssel unter https://docs.github.com/de/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent[Generieren und Hinzufügen eines SSH-Schlüssels^].

book/04-git-server/sections/git-daemon.asc

@@ -2,27 +2,27 @@
 
 (((Server-Repositorys, Git-Protocol)))
 Als Nächstes richten wir einen Daemon ein, der Repositorys mit dem „Git“-Protokoll versorgt.
-Das ist eine gängige Option für den schnellen, nicht authentifizierten Zugriff auf Ihre Git-Daten.
-Denken Sie daran, dass alles, was Sie über dieses Protokoll bereitstellen, innerhalb des Netzwerks öffentlich ist, da dies kein authentifizierter Dienst ist.
+Das ist eine gängige Option für den schnellen, nicht authentifizierten Zugriff auf deine Git-Daten.
+Denke daran, dass alles, was du über dieses Protokoll bereitstellst, innerhalb deines Netzwerks öffentlich ist, da dies kein authentifizierter Dienst ist.
 
-Wenn Sie Git auf einem Server außerhalb Ihrer Firewall ausführen, sollte dies nur für Projekte verwendet werden, die für die Welt öffentlich sichtbar sein dürfen.
-Wenn sich der Server, auf dem Sie es ausführen, hinter Ihrer Firewall befindet, können Sie es für Projekte verwenden, auf die eine große Anzahl von Personen oder Computern (Continuous Integration oder Build-Server) nur Lesezugriff haben, wenn Sie nicht für jeden einen SSH-Schlüssel hinzufügen möchten.
+Wenn du dieses auf einem Server außerhalb deiner Firewall ausführst, sollte dies nur für Projekte verwendet werden, die für die Welt öffentlich sichtbar sein dürfen.
+Wenn sich der genutzte Server, hinter deiner Firewall befindet, kannst du es für Projekte verwenden, auf die eine große Anzahl von Personen oder Computern (Continuous Integration oder Build-Server) nur Lesezugriff haben, wenn du nicht für jeden einen SSH-Schlüssel hinzufügen möchtest.
 
 In jedem Fall ist das Git-Protokoll relativ einfach einzurichten.
-Grundsätzlich müssen Sie diesen Befehl daemonisiert ausführen:(((Git Befehle, daemon)))
+Grundsätzlich solltest du diesen Befehl als Daemon auszuführen:(((Git Befehle, daemon)))
 
 [source,console]
 ----
 $ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
 ----
 
-Mit der `--reuseaddr` Option kann der Server neu gestartet werden, ohne dass das Zeitlimit für alte Verbindungen überschritten wird. Mit der `--base-path` Option können Benutzer Projekte klonen, ohne den gesamten Pfad anzugeben. Der Pfad am Ende teilt dem Git-Dämon mit, wo nach zu exportierenden Repositorys gesucht werden soll.
-Wenn Sie eine Firewall verwenden, müssen Sie auch an Port 9418 der Box, auf der Sie diese einrichten, ein Loch in die Firewall bohren.
+Mit der `--reuseaddr` Option kann der Server neu gestartet werden, ohne dass man auf eine Time-Out für alte Verbindungen warten muß. Mit der `--base-path` Option können Benutzer Projekte klonen, ohne den gesamten Pfad anzugeben. Der abschließende Pfad teilt dem Git-Daemon mit, wo nach zu exportierenden Repositorys gesucht werden soll.
+Wenn du eine Firewall verwendest, musst du den Port 9418 konfigurieren, um eingehende Verbindungen zuzulassen.
 
-Sie können diesen Prozess auf verschiedene Arten dämonisieren, je nachdem, welches Betriebssystem Sie verwenden.
+Du kannst diesen Prozess auf verschiedene Arten als Daemon betreiben, je nachdem, welches Betriebssystem du verwendest.
 
-Da `systemd` das gebräuchlichste Init-System unter modernen Linux-Distributionen ist, können Sie es für diesen Zweck verwenden.
-Legen Sie einfach eine Datei mit folgendem Inhalt in `/etc/systemd/system/git-daemon.service` ab:
+Das `systemd` ist das gebräuchlichste Init-System unter modernen Linux-Distributionen. Das könntest du für diesen Zweck verwenden.
+Lege einfach eine Datei mit folgendem Inhalt in `/etc/systemd/system/git-daemon.service` ab:
 
 [source,console]
 ----
@@ -46,21 +46,21 @@ Group=git
 WantedBy=multi-user.target
 ----
 
-Sie haben vielleicht bemerkt, dass der Git-Daemon hier mit `git` als Gruppe und Benutzer gestartet wird.
-Passen Sie es an Ihre Bedürfnisse an und stellen Sie sicher, dass der angegebene Benutzer auf dem System vorhanden ist.
-Überprüfen Sie auch, ob sich die Git-Binärdatei tatsächlich unter `/usr/bin/git` befindet und ändern Sie gegebenenfalls den Pfad.
+Du hast vielleicht bemerkt, dass der Git-Daemon hier mit `git` als Gruppe und Benutzer gestartet wird.
+Passe es an deine Bedürfnisse an und stelle sicher, dass der angegebene Benutzer auf dem System vorhanden ist.
+Überprüfe auch, ob sich die Git-Binärdatei tatsächlich unter `/usr/bin/git` befindet und ändere gegebenenfalls den Pfad.
 
-Abschließend führen Sie `systemctl enable git-daemon` aus, um den Dienst beim Booten automatisch zu starten, so dass Sie den Dienst mit `systemctl start git-daemon` und `systemctl stop git-daemon` starten und stoppen können.
+Abschließend führst du `systemctl enable git-daemon` aus, um den Dienst beim Booten automatisch zu starten, so dass du den Dienst mit `systemctl start git-daemon` und `systemctl stop git-daemon` starten und stoppen kannst.
 
-Auf anderen Systemen können Sie `xinetd` verwenden um ein Skript in Ihrem `sysvinit` System zu benutzen, oder etwas anderes – solange Sie diesen Befehl aktiviert und irgendwie überwacht bekommen.
+Auf anderen Systemen kannst du `xinetd` verwenden oder ein Skript in deinem `sysvinit` System benutzen. Auch andere Lösungen sind möglich, solange der Prozess als Daemon läuft und irgendwie überwacht wird.
 
-Als nächstes müssen Sie Git mitteilen, auf welche Repositorys nicht authentifizierter, serverbasierter Zugriff auf Git möglich sein soll.
-Sie können das in den einzelnen Repositorys tun, indem Sie eine Datei mit dem Namen `git-daemon-export-ok` erstellen.
+Als nächstes musst du Git mitteilen, auf welche Repositorys nicht authentifizierter, serverbasierter Zugriffe auf Git möglich sein soll.
+Du kannst das in den einzelnen Repositorys tun, indem du eine Datei mit dem Namen `git-daemon-export-ok` erstellst.
 
 [source,console]
 ----
 $ cd /path/to/project.git
 $ touch git-daemon-export-ok
 ----
 
-Das Vorhandensein dieser Datei teilt Git mit, dass es in Ordnung ist, dieses Projekt ohne Authentifizierung zu betreuen.
+Das Vorhandensein dieser Datei teilt Git mit, dass es in Ordnung ist, dieses Projekt ohne Authentifizierung zur Verfügung zu stellen.