Typo-Korrekturen4

de/history.txt

@@ -1,28 +1,28 @@
 == Geschichtsstunde ==
 
 Eine Folge von Git's verteilter Natur ist, dass die Chronik einfach
-verändert werden kann. Aber, wenn du an der Vergangenheit manipulierst, sei
-vorsichtig: verändere nur den Teil der Chronik, den du ganz alleine hast. So
+verändert werden kann. Aber, wenn Du an der Vergangenheit manipulierst, sei
+vorsichtig: verändere nur den Teil der Chronik, den Du ganz alleine hast. So
 wie Nationen ewig diskutieren, wer welche Greueltaten vollbracht hat, wirst
-du beim Abgleichen in Schwierigkeiten geraten, falls jemand einen 'Clone'
+Du beim Abgleichen in Schwierigkeiten geraten, falls jemand einen 'Clone'
 mit abweichender Chronik hat und die Zweige sich austauschen sollen.
 
 Einige Entwickler setzen sich nachhaltig für die Unantastbarkeit der Chronik
-ein, mit allen Fehlern, Nachteilen und Mängeln. Andere denken, daß Zweige
+ein, mit allen Fehlern, Nachteilen und Mängeln. Andere denken, dass Zweige
 vorzeigbar gemacht werden sollten, bevor sie auf die Öffentlichkeit
 losgelassen werden. Git versteht beide Gesichtspunkte. Wie 'Clonen',
 'Branchen' und 'Mergen' ist das Umschreiben der Chronik lediglich eine
-weitere Stärke, die Git dir bietet. Es liegt an dir diese weise zu nutzen.
+weitere Stärke, die Git Dir bietet. Es liegt an Dir, diese Weise zu nutzen.
 
 === Ich nehme alles zurück ===
 
-Hast du gerade 'commitet', aber du hättest gerne eine andere Beschreibung
+Hast Du gerade 'commitet', aber Du hättest gerne eine andere Beschreibung
 eingegeben? Dann gib ein:
 
  $ git commit --amend
 
-um die letzte Beschreibung zu ändern. Du merkst, dass du vergessen hast eine
-Datei hinzuzufügen? Führe *git add* aus um sie hinzuzufügen und dann die
+um die letzte Beschreibung zu ändern. Du merkst, dass Du vergessen hast eine
+Datei hinzuzufügen? Führe *git add* aus, um sie hinzuzufügen und dann die
 vorhergehende Anweisung.
 
 Du willst noch ein paar Änderungen zu deinem letzten 'Commit' hinzufügen?
@@ -33,8 +33,8 @@ Dann mache diese Änderungen und gib ein:
 === ... und noch viel mehr ===
 
 Nehmen wir jetzt an, das vorherige Problem ist zehnmal schlimmer. Nach einer
-längeren Sitzung hast du einen Haufen 'Commits' gemacht. Aber du bist mit
-der Art der Organisation nicht glücklich und einige 'Commits' könnten etwas
+längeren Sitzung hast Du einen Haufen 'Commits' gemacht. Aber Du bist mit
+der Art der Organisation nicht glücklich, und einige 'Commits' könnten etwas
 umformuliert werden. Dann gib ein:
 
  $ git rebase -i HEAD~10
@@ -67,49 +67,49 @@ Ansonsten:
 
 Also 'commite' früh und oft: du kannst später mit 'rebase' aufräumen.
 
-=== Lokale Änderungen zum Schluß ===
+=== Lokale Änderungen zum Schluss ===
 
 Du arbeitest an einem aktiven Projekt. Über die Zeit haben sich einige
-lokale 'Commits' angesammelt und dann synchronisierst du mit einem 'Merge'
-mit dem offiziellen Zweig. Dieser Zyklus wiederholt sich ein paar Mal bevor
-du zum 'Pushen' in den zentralen Zweig bereit bist.
+lokale 'Commits' angesammelt und dann synchronisierst Du mit einem 'Merge'
+mit dem offiziellen Zweig. Dieser Zyklus wiederholt sich ein paar Mal, bevor
+Du zum 'Pushen' in den zentralen Zweig bereit bist.
 
 Aber nun ist die Chronik in deinem lokalen Git-'Clone' ein chaotisches
 Durcheinander deiner Änderungen und den Änderungen vom offiziellen Zweig. Du
 willst alle Deine Änderungen lieber in einem fortlaufenden Abschnitt und
 hinter den offiziellen Änderungen sehen.
 
 Das ist eine Aufgabe für *git rebase*, wie oben beschrieben. In vielen
-Fällen kannst du den *--onto* Schalter benutzen um Interaktion zu vermeiden.
+Fällen kannst du den *--onto* Schalter benutzen, um Interaktion zu vermeiden.
 
 Siehe auch *git help rebase* für ausführliche Beispiele dieser erstaunlichen
 Anweisung. Du kannst auch 'Commits' aufteilen. Du kannst sogar 'Branches' in
 einem 'Repository' umorganisieren.
 
 === Chronik umschreiben ===
 
-Gelegentlich brauchst du Versionsverwaltung vergleichbar dem Wegretuschieren
+Gelegentlich brauchst Du Versionsverwaltung vergleichbar dem Wegretuschieren
 von Personen aus einem offiziellen Foto, um diese in stalinistischer Art aus
-der Geschichte zu löschen. Stell dir zum Beispiel vor, du willst ein Projekt
+der Geschichte zu löschen. Stell Dir zum Beispiel vor, Du willst ein Projekt
 veröffentlichen, aber es enthält eine Datei, die aus irgendwelchen Gründen
 privat bleiben muss. Vielleicht habe ich meine Kreditkartennummer in einer
 Textdatei notiert und diese versehentlich dem Projekt hinzugefügt. Die Datei
-zu löschen ist zwecklos, da über ältere 'Commits' auf sie zugegriffen werden
+zu löschen, ist zwecklos, da über ältere 'Commits' auf sie zugegriffen werden
 könnte. Wir müssen die Datei aus allen 'Commits' entfernen:
 
  $ git filter-branch --tree-filter 'rm sehr/geheime/Datei' HEAD
 
 Siehe *git help filter-branch*, wo dieses Beispiel erklärt und eine
-schnellere Methode vorstellt wird. Allgemein, *filter-branch* lässt dich
+schnellere Methode vorstellt wird. Allgemein, *filter-branch* lässt Dich
 große Bereiche der Chronik mit einer einzigen Anweisung verändern.
 
 Danach beschreibt der Ordner +.git/refs/original+ den Zustand der Lage vor
-der Operation. Prüfe, ob die 'filter-branch' Anweisung getan hat was du
-wolltest, dann lösche dieses Verzeichnis bevor du weitere 'filter-branch'
+der Operation. Prüfe, ob die 'filter-branch' Anweisung getan hat, was du
+wolltest, dann lösche dieses Verzeichnis, bevor Du weitere 'filter-branch'
 Operationen durchführst.
 
-Zuletzt, ersetze alle 'Clones' deines Projekts mit deiner überarbeiteten
-Version, falls du später mit ihnen interagieren möchtest.
+Zuletzt, ersetze alle 'Clones' Deines Projekts mit deiner überarbeiteten
+Version, falls Du später mit ihnen interagieren möchtest.
 
 === Geschichte machen ===
 
@@ -119,9 +119,9 @@ jemand ein Skript geschrieben hat, das die gesamte Chronik für Git
 exportiert.
 
 Anderenfalls, sieh dir *git fast-import* an, das Text in einem speziellen
-Format einliest um eine Git Chronik von Anfang an zu
+Format einliest, um eine Git Chronik von Anfang an zu
 erstellen. Normalerweise wird ein Skript, das diese Anweisung benutzt,
-hastig zusammengeschustert und einmalig ausgeführt um das Projekt in einem
+hastig zusammengeschustert und einmalig ausgeführt, um das Projekt in einem
 einzigen Lauf zu migrieren.
 
 Erstelle zum Beispiel aus folgendem Listing eine temporäre Datei, z.B. `/tmp/history`:
@@ -157,40 +157,40 @@ Eingabe von:
  $ mkdir project; cd project; git init
  $ git fast-import --date-format=rfc2822 < /tmp/history
 
-Die aktuellste Version des Projekts kannst du abrufen ('checkout') mit:
+Die aktuellste Version des Projekts kannst Du abrufen ('checkout') mit:
 
  $ git checkout master .
 
 Die Anweisung *git fast-export* konvertiert jedes 'Repository' in das *git
-fast-import* Format, diese Ausgabe kannst du studieren um Exporteure zu
-schreiben und außerdem um 'Repositories' in Klartext zu übertragen.
-untersuchen wes you can study for writing exporters, and also to transport
-repositories in a human-readable format. Wirklich, diese Anweisung kann
-Klartext-'Repositories' über reine Textkanäle übertragen.
+fast-import* Format, dessen Ausgabe Du studieren kannst, um Exporteure zu
+schreiben und außerdem, um 'Repositories' im menschenlesbaren Text zu übertragen.
+
+Tatsächlich können diese Anweisungen Klartext-'Repositories' über reine
+Textkanäle übertragen.
 
 === Wo ging alles schief? ===
 
-Du hast gerade ein Funktion in deiner Anwendung entdeckt, die nicht mehr
+Du hast gerade eine Funktion in deiner Anwendung entdeckt, die nicht mehr
 funktioniert und du weißt sicher, dass sie vor ein paar Monaten noch
-ging. Argh! Wo kommt dieser Fehler her? Hättest du nur die Funktion während
+ging. Argh! Wo kommt dieser Fehler her? Hättest Du nur die Funktion während
 der Entwicklung getestet.
 
-Dafür ist es nun zu spät. Wie auch immer, vorausgesetzt du hast oft
-'comittet', kann Git dir sagen, wo das Problem liegt:
+Dafür ist es nun zu spät. Wie auch immer, vorausgesetzt Du hast oft
+'comittet', kann Git Dir sagen, wo das Problem liegt:
 
  $ git bisect start
  $ git bisect bad HEAD
  $ git bisect good 1b6d
 
-Git ruft eine Stand ab, der genau dazwischen liegt. Teste die Funktion und
-wenn sich immer noch nicht funktioniert:
+Git ruft einen Stand ab, der genau dazwischen liegt. Teste die Funktion und
+wenn sie immer noch nicht funktioniert:
 
  $ git bisect bad
 
-Wenn nicht, ersetzte "bad" mit "good". Git versetzt dich wieder auf einen
+Wenn nicht, ersetzte "bad" mit "good". Git versetzt Dich wieder auf einen
 Stand genau zwischen den bekannten Versionen "good" und "bad" und reduziert
-so die Möglichkeiten. Nach ein paar Durchläufen wird dich diese binäre Suche
-zu dem 'Commit' führen, der die Probleme verursacht. Wenn du deine
+so die Möglichkeiten. Nach ein paar Durchläufen wird Dich diese binäre Suche
+zu dem 'Commit' führen, der die Probleme verursacht. Wenn Du deine
 Ermittlungen abgeschlossen hast, kehre zum Originalstand zurück mit:
 
  $ git bisect reset
@@ -209,7 +209,7 @@ zwischen 1 und 127 für 'bad'. Ein negativer Rückgabewert beendet die
 
 Du kannst noch viel mehr machen: die Hilfe erklärt, wie man
 'bisect'-Operationen visualisiert, das 'bisect'-Log untersucht oder
-wiedergibt und sicher unschuldige Änderungen ausschließt um die Suche zu
+wiedergibt und sicher unschuldige Änderungen ausschließt, um die Suche zu
 beschleunigen.
 
 === Wer ist verantwortlich? ===
@@ -218,7 +218,7 @@ Wie viele andere Versionsverwaltungssysteme hat Git eine 'blame' Anweisung:
 
  $ git blame bug.c
 
-das jede Zeile in der angegebenen Datei kommentiert um anzuzeigen, wer sie
+das jede Zeile in der angegebenen Datei kommentiert, um anzuzeigen, wer sie
 zuletzt geändert hat und wann. Im Gegensatz zu vielen anderen
 Versionsverwaltungssystemen funktioniert diese Operation offline, es wird
 nur von der lokalen Festplatte gelesen.
@@ -230,10 +230,10 @@ Chronik eine schwierige Angelegenheit und den Administratoren
 vorbehalten. 'Clonen', 'Branchen' und 'Mergen' sind unmöglich ohne
 Netzwerkverbindung. Ebenso grundlegende Funktionen wie das Durchsuchen der
 Chronik oder das 'comitten' einer Änderung. In manchen Systemen benötigt der
-Anwender schon eine Netzwerkverbindung nur um seine eigenen Änderungen zu
+Anwender schon eine Netzwerkverbindung, nur um seine eigenen Änderungen zu
 sehen oder um eine Datei zum Bearbeiten zu öffnen.
 
-Zentralisierte Systeme schließen es aus offline zu arbeiten und benötigen
+Zentralisierte Systeme schließen es aus, offline zu arbeiten und benötigen
 teurere Netzwerkinfrastruktur, vor allem, wenn die Zahl der Entwickler
 steigt. Am wichtigsten ist, dass alle Operationen bis zu einem gewissen Grad
 langsamer sind, in der Regel bis zu dem Punkt, wo Anwender erweiterte
@@ -249,27 +249,27 @@ selbstverständlich. Ich habe einfach vorausgesetzt, dass andere Systeme
 ähnlich sind: die Auswahl eines Versionsverwaltungssystems sollte nicht
 anders sein als die Auswahl eines Texteditors oder Internetbrowser.
 
-Ich war geschockt, als ich später gezwungen war ein zentralisiertes System
+Ich war geschockt, als ich später gezwungen war, ein zentralisiertes System
 zu benutzen. Eine unzuverlässige Internetverbindung stört mit Git nicht
 sehr, aber sie macht die Entwicklung unerträglich, wenn sie so zuverlässig
 wie ein lokale Festplatte sein sollte. Zusätzlich habe ich mich dabei
 ertappt, bestimmte Anweisungen zu vermeiden, um die damit verbundenen
-Wartezeiten zu vermeiden und das hat mich letztendlich davon abgehalten
+Wartezeiten zu vermeiden und das hat mich letztendlich davon abgehalten,
 meinem gewohnten Arbeitsablauf zu folgen.
 
 Wenn ich eine langsame Anweisung auszuführen hatte, wurde durch die
 Unterbrechung meiner Gedankengänge dem Arbeitsfluss ein unverhältnismäßiger
-Schaden zugefügt. Während dem Warten auf das Ende der Serverkommunikation
-tat ich etwas anderes um die Wartezeit zu überbrücken, zum Beispiel E-Mails
+Schaden zugefügt. Während des Wartens auf das Ende der Serverkommunikation
+tat ich etwas anderes, um die Wartezeit zu überbrücken, zum Beispiel E-Mails
 lesen oder Dokumentation schreiben. Wenn ich zur ursprünglichen Arbeit
 zurückkehrte, war die Operation längst beendet und ich vergeudete noch mehr
-Zeit beim Versuch mich zu erinnern was ich getan habe. Menschen sind nicht
+Zeit beim Versuch, mich zu erinnern, was ich getan habe. Menschen sind nicht
 gut im Kontextwechsel.
 
 Da war auch ein interessanter
 http://de.wikipedia.org/wiki/Tragik_der_Allmende[Tragik-der-Allmende]
 Effekt: Netzwerküberlastungen erahnend, verbrauchten einzelne Individuen für
 diverse Operationen mehr Netzwerkbandbreite als erforderlich, um zukünftige
 Engpässe zu vermeiden. Die Summe der Bemühungen verschlimmerte die
-Überlastungen, was einzelne wiederum ermutigte noch mehr Bandbreite zu
-verbrauchen um noch längere Wartezeiten zu verhindern.
+Überlastungen, was einzelne wiederum ermutigte, noch mehr Bandbreite zu
+verbrauchen, um noch längere Wartezeiten zu verhindern.