ch12 vom Sie zum Du (#398)

Author: pastatopf

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

@@ -1,7 +1,7 @@
 === Was ist Versionsverwaltung?
 
 (((Versionsverwaltung)))
-Was ist „Versionsverwaltung“, und warum sollten Sie sich dafür interessieren?
+Was ist „Versionsverwaltung“, und warum solltest du dich dafür interessieren?
 Versionsverwaltung ist ein System, welches die Änderungen an einer oder einer Reihe von Dateien über die Zeit hinweg protokolliert, sodass man später auf eine bestimmte Version zurückgreifen kann.
 Die Dateien, die in den Beispielen in diesem Buch unter Versionsverwaltung gestellt werden, enthalten Quelltext von Software. Tatsächlich kann in der Praxis nahezu jede Art von Datei per Versionsverwaltung nachverfolgt werden.
 

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

@@ -221,7 +221,7 @@ Wenn jetzt jemand anderes aus deinem Repository klont oder pullt, erhält er auc
 .`git push` pusht beide Arten von Tags
 ====
 `git push <remote> --tags` wird sowohl Lightweight- als auch Annotated-Tags pushen.
-Es gibt zur Zeit keine Möglichkeit, nur Lightweight-Tags zu pushen, aber wenn Sie `git push <remote> --follow-tags` verwenden, werden nur annotierte Tags an den Remote gepusht.
+Es gibt zur Zeit keine Möglichkeit, nur Lightweight-Tags zu pushen, aber wenn du `git push <remote> --follow-tags` verwendest, werden nur annotierte Tags an den Remote gepusht.
 ====
 
 ==== Tags löschen

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

@@ -7,7 +7,7 @@ Du kannst eine vollständige, ausführliche Liste von Remote-Referenzen bekommen
 Der gängigerer Ansatz ist jedoch die Nutzung von Remote-Tracking-Branches.
 
 Remote-Tracking-Branches sind Referenzen auf den Zustand von Remote-Branches.
-Sie sind lokale Referenzen, die du nicht manuell ändern kannst. Sie werden automatisch für dich geändert, sobald Sie irgendeine Netzwerkkommunikation durchführen.
+Sie sind lokale Referenzen, die du nicht manuell ändern kannst. Sie werden automatisch für dich geändert, sobald du irgendeine Netzwerkkommunikation durchführst.
 Betrachte sie als Lesezeichen, die daran erinnern, wo die Branches in deinem Remote-Repositorys das letzte Mal standen, als du dich mit ihnen verbunden hast.
 
 Remote-Tracking-Branch-Namen haben die Form `<remote>/<branch>`.

book/10-git-internals/sections/environment.asc

@@ -1,25 +1,25 @@
 ` === Umgebungsvariablen
 
 Git läuft immer in einer `bash` Shell und verwendet eine Reihe von Shell-Umgebungsvariablen, über die man steuern kann, wie es sich verhält.
-Gelegentlich ist es hilfreich zu wissen, welche diese sind und wie Sie Git dazu bringen können, sich so zu verhalten, wie Sie es möchten.
+Gelegentlich ist es hilfreich zu wissen, welche diese sind und wie du Git dazu bringen kannst, sich so zu verhalten, wie du es möchtest.
 Dies ist keine vollständige Liste aller Umgebungsvariablen auf die Git achtet, aber wir werden die nützlichsten behandeln.
 
 
-==== Globals Verhalten
+==== Globales Verhalten
 
 Einige der generellen Eigenschaften von Git als Computerprogramm hängen von Umgebungsvariablen ab.
 
 *`GIT_EXEC_PATH`* bestimmt, wo Git nach seinen Unterprogrammen sucht (wie `git-commit`, `git-diff` und andere).
-  Sie können die aktuelle Einstellung überprüfen, indem Sie `git --exec-path` ausführen.
+  Du kannst die aktuelle Einstellung überprüfen, indem du `git --exec-path` ausführst.
 
 *`HOME`* wird normalerweise nicht als anpassbar angesehen (zu viele andere Dinge hängen davon ab), aber hier sucht Git nach der globalen Konfigurationsdatei.
-  Wenn Sie eine wirklich portable Git-Installation mit globaler Konfiguration wünschen, können Sie `HOME` im portablen Git Shell-Profil überschreiben.
+  Wenn du eine wirklich portable Git-Installation mit globaler Konfiguration wünschst, kannst du `HOME` im portablen Git Shell-Profil überschreiben.
 
 *`PREFIX`* ist ähnlich, jedoch für die systemweite Konfiguration.
   Git sucht nach dieser Datei unter `$PREFIX/etc/gitconfig`.
 
 *`GIT_CONFIG_NOSYSTEM`*, falls gesetzt, deaktiviert die Verwendung der systemweiten Konfigurationsdatei.
-  Dies ist nützlich, wenn Ihre Systemkonfiguration Ihre Befehle beeinträchtigt, Sie jedoch keinen Zugriff haben, um diese zu ändern oder zu entfernen.
+  Dies ist nützlich, wenn deine Systemkonfiguration deine Befehle beeinträchtigt, du jedoch keinen Zugriff hast, um diese zu ändern oder zu entfernen.
 
 *`GIT_PAGER`* steuert das Programm, mit dem mehrseitige Ausgaben in der Befehlszeile angezeigt werden.
 Ist dies nicht gesetzt, wird `PAGER` als Fallback verwendet.
@@ -36,27 +36,27 @@ Git verwendet mehrere Umgebungsvariablen, um die Verbindung zum aktuellen Reposi
 Wenn dies nicht angegeben ist, geht Git nach oben durch den Verzeichnisbaum, bis es zu `~` oder `/` gelangt, und sucht bei jedem Schritt nach einem `.git` Verzeichnis.
 
 *`GIT_CEILING_DIRECTORIES`* steuert das Verhalten bei der Suche nach einem `.git` Verzeichnis.
-Wenn Sie auf Verzeichnisse zugreifen, die nur langsam geladen werden können (z.B. auf einem Bandlaufwerk oder über eine langsame Netzwerkverbindung), möchten Sie möglicherweise, dass Git den Versuch vorzeitig abbricht, insbesondere wenn Git in der Kommandozeile aufgerufen wird.
+Wenn du auf Verzeichnisse zugreifst, die nur langsam geladen werden können (z.B. auf einem Bandlaufwerk oder über eine langsame Netzwerkverbindung), möchtest du möglicherweise, dass Git den Versuch vorzeitig abbricht, insbesondere wenn Git in der Kommandozeile aufgerufen wird.
 
 *`GIT_WORK_TREE`* ist der Speicherort des Stammverzeichnisses eines Arbeitsverzeichnisses für ein non-bare Repository.
-Wenn `--git-dir` oder `GIT_DIR` angegeben ist, jedoch nicht `--work-tree`, `GIT_WORK_TREE` oder `core.worktree`, wird das aktuelle Arbeitsverzeichnis als oberste Ebene Ihres Arbeitsbaums betrachtet.
+Wenn `--git-dir` oder `GIT_DIR` angegeben ist, jedoch nicht `--work-tree`, `GIT_WORK_TREE` oder `core.worktree`, wird das aktuelle Arbeitsverzeichnis als oberste Ebene deines Arbeitsbaums betrachtet.
 
 *`GIT_INDEX_FILE`* ist der Pfad zur Indexdatei (nur für non-bare Repositorys).
 
 *`GIT_OBJECT_DIRECTORY`* kann verwendet werden, um den Speicherort des Verzeichnisses anzugeben, das sich normalerweise in `.git/objects` befindet.
 
 *`GIT_ALTERNATE_OBJECT_DIRECTORIES`* ist eine durch Doppelpunkte getrennte Liste (also im Format `/dir/one:/dir/two:… `), die Git mitteilt, wo nach Objekten gesucht werden soll, wenn sie sich nicht in` GIT_OBJECT_DIRECTORY` befinden.
-Wenn Sie viele Projekte mit großen Dateien haben, die genau den gleichen Inhalt haben, können Sie damit vermeiden, dass zu viele Kopien davon gespeichert werden.
+Wenn du viele Projekte mit großen Dateien hast, die genau den gleichen Inhalt haben, kannst du damit vermeiden, dass zu viele Kopien davon gespeichert werden.
 
 
 ==== Pfadspezifikation (engl. Pathspec)
 
-„Pathspec“ bezieht sich darauf, wie Sie Pfade in Git angeben, einschließlich der Verwendung von Platzhaltern.
+„Pathspec“ bezieht sich darauf, wie du Pfade in Git angibst, einschließlich der Verwendung von Platzhaltern.
 Diese werden in der Datei `.gitignore` aber auch in der Befehlszeile (`git add *.c`) verwendet.
 
 *`GIT_GLOB_PATHSPECS`* und *`GIT_NOGLOB_PATHSPECS`* steuern das Standardverhalten von Platzhaltern in Pfadangaben.
 Wenn `GIT_GLOB_PATHSPECS` auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn `GIT_NOGLOB_PATHSPECS` auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass `*.c` nur mit einer Datei namens „* .c“ übereinstimmt und nicht mit einer Datei, deren Name mit `.c` endet.
-Sie können dies in Einzelfällen überschreiben, indem Sie die Pfadangabe mit `:(glob)` oder `:(literal)` beginnen, wie in `:(glob)*.c`.
+Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit `:(glob)` oder `:(literal)` beginnst, wie in `:(glob)*.c`.
 
 *`GIT_LITERAL_PATHSPECS`* deaktiviert beide oben genannten Verhaltensweisen. Es können keine Platzhalterzeichen verwendet werden, und die Präfixe zum Überschreiben sind ebenfalls deaktiviert.
 
@@ -89,7 +89,7 @@ Git verwendet die Bibliothek `curl`, um Netzwerkoperationen über HTTP durchzuf
 Dies ähnelt dem Ausführen von `curl -v` in der Befehlszeile.
 
 *`GIT_SSL_NO_VERIFY`* weist Git an, SSL-Zertifikate nicht zu verifizieren.
-Dies kann manchmal erforderlich sein, wenn Sie ein selbstsigniertes Zertifikat verwenden, um Git-Repositorys über HTTPS bereitzustellen, oder wenn Sie gerade einen Git-Server einrichten, aber noch kein vollständiges Zertifikat installiert haben.
+Dies kann manchmal erforderlich sein, wenn du ein selbstsigniertes Zertifikat verwendest, um Git-Repositorys über HTTPS bereitzustellen, oder wenn du gerade einen Git-Server einrichtest, aber noch kein vollständiges Zertifikat installiert hast.
 
 
 Wenn die Datenrate einer HTTP-Operation unter *`GIT_HTTP_LOW_SPEED_LIMIT`* Bytes pro Sekunde und länger als *`GIT_HTTP_LOW_SPEED_TIME`* Sekunden anhält, bricht Git diese Operation ab.
@@ -124,8 +124,8 @@ Der Standardwert ist 2.
 
 ==== Debugging
 
-Möchten Sie wirklich wissen, was in Git abgeht?
-In Git ist eine umfangreiche Sammlung von Traces eingebettet, alles was Sie tun müssen, ist sie einzuschalten.
+Möchtest du wirklich wissen, was in Git abgeht?
+In Git ist eine umfangreiche Sammlung von Traces eingebettet. Alles was du tun musst, ist sie einzuschalten.
 Die möglichen Werte dieser Variablen lauten wie folgt:
 
 * „true“, „1“ oder „2“ - die Trace-Kategorie wird nach stderr geschrieben.
@@ -216,20 +216,20 @@ nothing to commit, working directory clean
 
 *`GIT_SSH`*, falls angegeben, ist ein Programm, das anstelle von `ssh` aufgerufen wird, um eine Verbindung zu einem SSH-Host herzustellen.
 Es wird folgendermaßen aufgerufen: `$GIT_SSH [username@]host [-p <port>] <befehl>`.
-Beachten Sie, dass dies nicht der einfachste Weg ist, um zu konfigurieren, wie `ssh` aufgerufen wird. Es werden keine zusätzlichen Befehlszeilenparameter unterstützt, daher müssen Sie ein Wrapper-Skript schreiben und `GIT_SSH` so einstellen, dass es darauf verweist.
+Beachte, dass dies nicht der einfachste Weg ist, um zu konfigurieren, wie `ssh` aufgerufen wird. Es werden keine zusätzlichen Befehlszeilenparameter unterstützt, daher musst du ein Wrapper-Skript schreiben und `GIT_SSH` so einstellen, dass es darauf verweist.
 Es ist wahrscheinlich einfacher, dafür einfach die Datei `~/.ssh/config` zu verwenden.
 
 *`GIT_ASKPASS`* dient zur Überschreibung des Konfigurationswertes `core.askpass`.
-Dies ist das Programm, das immer dann aufgerufen wird, wenn Git den Benutzer nach Anmeldeinformationen fragen muss, wobei eine Eingabeaufforderung als Befehlszeilenargument erwartet wird und die eine Antwort auf `stdout` zurückgeben soll. Weitere Informationen zu diesem Subsystem finden Sie unter <<ch07-git-tools#_credential_caching>>.
+Dies ist das Programm, das immer dann aufgerufen wird, wenn Git den Benutzer nach Anmeldeinformationen fragen muss, wobei eine Eingabeaufforderung als Befehlszeilenargument erwartet wird und die eine Antwort auf `stdout` zurückgeben soll. Weitere Informationen zu diesem Subsystem findest du unter <<ch07-git-tools#_credential_caching>>.
 
 *`GIT_NAMESPACE`* steuert den Zugriff auf namenspaced refs und entspricht dem Flag `--namespace`.
-Dies ist vor allem auf der Serverseite nützlich, wo Sie möglicherweise mehrere Forks eines einzelnen Repositorys in einem Repository speichern möchten, wobei nur die Refs getrennt bleiben.
+Dies ist vor allem auf der Serverseite nützlich, wo du möglicherweise mehrere Forks eines einzelnen Repositorys in einem Repository speichern möchtest, wobei nur die Refs getrennt bleiben.
 
 *`GIT_FLUSH`* kann verwendet werden, um Git zu zwingen, nicht gepuffertes I/O zu verwenden, wenn inkrementell in stdout geschrieben wird.
 Ein Wert von 1 bewirkt, dass Gits Puffer öfter geleert wird. Ein Wert von 0 bewirkt, dass alle Ausgaben gepuffert werden.
 Der Standardwert (falls diese Variable nicht festgelegt ist) ist die Auswahl eines geeigneten Pufferschemas abhängig von Aktivität und Ausgabemodus.
 
-Mit *`GIT_REFLOG_ACTION`* können Sie den beschreibenden Text angeben, der in das Reflog geschrieben wird.
+Mit *`GIT_REFLOG_ACTION`* kannst du den beschreibenden Text angeben, der in das Reflog geschrieben wird.
 Hier ein Beispiel:
 
 [source,console]