Typo-Korrekturen

de/basic.txt

@@ -7,7 +7,7 @@ mehr als in diesem Kapitel beschrieben steht.
 
 === Stand sichern ===
 
-Hast du gravierende Änderungen vor? Nur zu, aber speichere deinen aktuellen
+Hast Du gravierende Änderungen vor? Nur zu, aber speichere Deinen aktuellen
 Stand vorher lieber nochmal ab:
 
  $ git init
@@ -25,8 +25,8 @@ Um den neuen Stand zu sichern:
 
 === Hinzufügen, Löschen, Umbenennen ===
 
-Bisher kümmert sich Git nur um Dateien, die existierten, als du das erste
-Mal *git add* ausgeführt hast. Wenn du Dateien oder Verzeichnisse
+Bisher kümmert sich Git nur um Dateien, die existierten, als Du das erste
+Mal *git add* ausgeführt hast. Wenn Du Dateien oder Verzeichnisse
 hinzufügst, musst du Git das mitteilen:
 
  $ git add readme.txt Dokumentation
@@ -36,22 +36,22 @@ Ebenso, wenn Git Dateien vergessen soll:
  $ git rm ramsch.h veraltet.c
  $ git rm -r belastendes/material/
 
-Git löscht diese Dateien für dich, falls du es noch nicht getan hast.
+Git löscht diese Dateien für Dich, falls Du es noch nicht getan hast.
 
-Eine Datei umzubenennen ist das selbe wie sie zu löschen und unter neuem
+Eine Datei umzubenennen, ist das selbe, wie sie zu löschen und unter neuem
 Namen hinzuzufügen. Git benutzt hierzu die Abkürzung *git mv*, welche die
 gleiche Syntax wie *mv* hat. Zum Beispiel:
 
  $ git mv fehler.c feature.c
 
 === Fortgeschrittenes Rückgängig machen/Wiederherstellen ===
 
-Manchmal möchtest du einfach zurück gehen und alle Änderungen ab einem
+Manchmal möchtest Du einfach zurückgehen und alle Änderungen ab einem
 bestimmten Zeitpunkt verwerfen, weil sie falsch waren. Dann:
 
  $ git log
 
-zeigt dir eine Liste der bisherigen 'Commits' und deren SHA1 Hashwerte:
+zeigt Dir eine Liste der bisherigen 'Commits' und deren SHA1 Hashwerte:
 
 ----------------------------------
 commit 766f9881690d240ba334153047649b8b8f11c664
@@ -76,45 +76,45 @@ Hashwert. Gib ein:
 um den Stand eines bestimmten 'Commits' wieder herzustellen und alle
 nachfolgenden Änderungen für immer zu löschen.
 
-Ein anderes Mal willst du nur kurz zu einem älteren Stand springen. In
+Ein anderes Mal willst Du nur kurz zu einem älteren Stand springen. In
 diesem Fall, gib folgendes ein:
 
  $ git checkout 82f5
 
-Damit springst du in der Zeit zurück, behältst aber neuere Änderungen. Aber,
-wie bei Zeitreisen in einem Science-Fiction-Film, wenn du jetzt etwas
-änderst und 'commitest', gelangst du in ein alternative Realität, denn deine
+Damit springst Du in der Zeit zurück, behältst aber neuere Änderungen. Aber,
+wie bei Zeitreisen in einem Science-Fiction-Film, wenn Du jetzt etwas
+änderst und 'commitest', gelangst Du in ein alternative Realität, denn Deine
 Änderungen sind anders als beim früheren 'Commit'.
 
 Diese alternative Realität heißt 'Branch' und <<branch,wir kommen später
-darauf zurück>>. Für jetzt, merke dir
+darauf zurück>>. Für jetzt, merke Dir
 
  $ git checkout master
 
-bringt dich wieder in die Gegenwart. Um zu verhindern, dass sich Git
-beschwert, solltest du vor einem 'Checkout' alle Änderungen 'commiten' oder
+bringt Dich wieder in die Gegenwart. Um zu verhindern, dass sich Git
+beschwert, solltest Du vor einem 'Checkout' alle Änderungen 'commiten' oder
 'reseten'.
 
 Um wieder die Computerspielanalogie anzuwenden:
 
 - *`git reset --hard`*: Lade einen alten Stand und lösche alle Spielstände,
 die neuer sind als der jetzt geladene.
 
-- *`git checkout`*: Lade einen alten Spielstand, aber wenn du weiterspielst,
+- *`git checkout`*: Lade einen alten Spielstand, aber wenn Du weiterspielst,
 wird der Spielstand von den früher gesicherten Spielständen abweichen. Jeder
 Spielstand, der ab jetzt gesichert wird, entsteht in dem separaten 'Branch',
-welcher der alternative Realität entspricht. <<branch,Dazu kommen wir
+welcher der alternative Realität entspricht. <<branch, dazu kommen wir
 später>>.
 
-Du kannst auch nur einzelne Dateien oder Verzeichnisse wiederherstellen
-indem du sie an den Befehl anhängst:
+Du kannst auch nur einzelne Dateien oder Verzeichnisse wiederherstellen,
+indem Du sie an den Befehl anhängst:
 
  $ git checkout 82f5 eine.datei andere.datei
 
-Sei Vorsichtig, diese Art des '*Checkout*' kann Dateien überschreiben, ohne
-dass du etwas merkst. Um Unfälle zu vermeiden solltest du immer 'commiten'
-bevor du ein 'Checkout' machst, besonders am Anfang wenn du Git noch
-erlernst. Allgemein gilt: Wenn du unsicher bist, egal ob ein Git Befehl oder
+Sei vorsichtig, diese Art des '*Checkout*' kann Dateien überschreiben, ohne
+dass Du etwas merkst. Um Unfälle zu vermeiden, solltest Du immer 'commiten'
+bevor du ein 'Checkout' machst, besonders am Anfang, wenn Du Git noch
+erlernst. Allgemein gilt: Wenn Du unsicher bist, egal, ob ein Git Befehl oder
 irgendeine andere Operation, führe zuerst *git commit -a* aus.
 
 Du magst Kopieren und Einfügen von Hashes nicht? Dann nutze:
@@ -129,7 +129,7 @@ auch nach dem 5. letzten 'Commit' fragen:
 === Rückgängig machen ===
 
 In einem Gerichtssaal können Ereignisse aus den Akten gelöscht
-werden. Ähnlich kannst du gezielt 'Commits' rückgängig machen.
+werden. Ähnlich kannst Du gezielt 'Commits' rückgängig machen.
 
  $ git commit -a
  $ git revert 1b6d
@@ -161,17 +161,17 @@ Es gibt gleich noch viel mehr über den 'clone' Befehl zu sagen.
 
 === Das Neueste vom Neuen ===
 
-Wenn du schon eine Kopie eines Projektes hast, kannst du es auf die neuste
+Wenn Du schon eine Kopie eines Projektes hast, kannst Du es auf die neuste
 Version aktualisieren mit:
 
  $ git pull
 
 === Einfaches Veröffentlichen ===
 
-Angenommen du hast ein Skript geschrieben und möchtest es anderen zugänglich
-machen. Du könntest sie einfach bitten es von deinem Computer
-herunterzuladen, aber falls sie das tun während du experimentierst oder das
-Skript verbesserst könnten sie in Schwierigkeiten geraten. Genau deswegen
+Angenommen Du hast ein Skript geschrieben und möchtest es anderen zugänglich
+machen. Du könntest sie einfach bitten, es von deinem Computer
+herunterzuladen, aber falls sie das tun, während du experimentierst oder das
+Skript verbesserst, könnten sie in Schwierigkeiten geraten. Genau deswegen
 gibt es Releasezyklen. Entwickler arbeiten regelmäßig an einem Projekt,
 veröffentlichen den Code aber nur, wenn sie ihn für vorzeigbar halten.
 
@@ -181,30 +181,30 @@ Um dies in Git zu tun, gehe ins Verzeichnis in dem das Skript liegt:
  $ git add .
  $ git commit -m "Erster Stand"
 
-Dann sage deinen Nutzern:
+Dann sage Deinen Nutzern:
 
  $ git clone dein.computer:/pfad/zum/skript
 
-um dein Skript herunterzuladen. Das setzt voraus, dass sie einen SSH-Zugang
+um Dein Skript herunterzuladen. Das setzt voraus, dass sie einen SSH-Zugang
 haben. Falls nicht, führe *git deamon* aus und sage den Nutzern folgendes:
 
  $ git clone git://dein.computer/pfad/zum/skript
 
-Ab jetzt, immer wenn dein Skript reif für eine Veröffentlichung ist:
+Ab jetzt, immer wenn Dein Skript reif für eine Veröffentlichung ist:
 
  $ git commit -a -m "Nächster Stand"
 
-und deine Nutzer können ihr Skript aktualisieren mit:
+und Deine Nutzer können ihr Skript aktualisieren mit:
 
  $ git pull
 
-Deine Nutzer werden nie mit Versionen in Kontakt kommen, von denen du es
+Deine Nutzer werden nie mit Versionen in Kontakt kommen, von denen Du es
 nicht willst. Natürlich funktioniert der Trick für fast alles, nicht nur
 Skripts.
 
 === Was habe ich getan? ===
 
-Finde heraus was du seit dem letzten 'Commit' getan hast:
+Finde heraus, was Du seit dem letzten 'Commit' getan hast:
 
  $ git diff
 
@@ -216,22 +216,22 @@ Oder zwischen irgendeiner Version und der vorvorletzten:
 
  $ git diff 1b6d "master~2"
 
-Jedes mal ist die Ausgabe ein 'Patch' der mit *git apply* eingespielt werden
+Jedes mal ist die Ausgabe ein 'Patch', der mit *git apply* eingespielt werden
 kann. Versuche auch:
 
  $ git whatchanged --since="2 weeks ago"
 
-Um mir die Geschichte eines 'Repositories' anzuzeigen benutze ich häufig
+Um mir die Geschichte eines 'Repositories' anzuzeigen, benutze ich häufig
 http://sourceforge.net/projects/qgit[qgit] da es eine schicke
 Benutzeroberfläche hat, oder http://jonas.nitro.dk/tig/[tig], eine
 Konsolenanwendung, die sehr gut über langsame Verbindungen
-funktioniert. Alternativ kannst du einen Webserver installieren mit *git
-instaweb*, dann kannst du mit jedem Webbrowser darauf zugreifen.
+funktioniert. Alternativ kannst Du einen Webserver installieren mit *git
+instaweb*, dann kannst Du mit jedem Webbrowser darauf zugreifen.
 
 === Übung ===
 
 A, B, C, D sind 4 aufeinander folgende 'Commits'. B ist identisch mit A,
-außer dass einige Dateien gelöscht wurden. Wir möchten die Dateien in D
+außer, dass einige Dateien gelöscht wurden. Wir möchten die Dateien in D
 wieder hinzufügen, aber nicht in B. Wie machen wir das?
 
 Es gibt mindestens 3 Lösungen. Angenommen, wir sind bei D:
@@ -252,6 +252,6 @@ Es gibt mindestens 3 Lösungen. Angenommen, wir sind bei D:
 
    $ git revert B
 
-Welche Lösung ist die beste? Die, welche dir am besten gefällt. Es ist
-einfach mit Git das zu bekommen was du willst und oft führen viele Wege zum
+Welche Lösung ist die beste? Die, welche Dir am besten gefällt. Es ist
+einfach, mit Git das zu bekommen, was Du willst und oft führen viele Wege zum
 Ziel.

de/intro.txt

@@ -1,71 +1,71 @@
 == Einleitung ==
 
-Ich benutze eine Analogie um in die Versionsverwaltung einzuführen. Für eine
+Ich benutze eine Analogie, um in die Versionsverwaltung einzuführen. Für eine
 vernünftigere Erklärung siehe
 http://de.wikipedia.org/wiki/Versionsverwaltung[den Wikipedia Artikel zur
 Versionsverwaltung].
 
 === Arbeit ist Spiel ===
 
 Ich spiele Computerspiele schon fast mein ganzes Leben. Im Gegensatz dazu
-habe ich erst als Erwachsener damit begonnen Versionsverwaltungssysteme zu
-benutzen. Ich vermute, dass ich damit nicht alleine bin und der Vergleich
-hilft vielleicht dabei die Konzepte einfacher zu erklären und zu verstehen.
+habe ich erst als Erwachsener damit begonnen, Versionsverwaltungssysteme zu
+benutzen. Ich vermute, dass ich damit nicht alleine bin, und der Vergleich
+hilft vielleicht, dabei die Konzepte einfacher zu erklären und zu verstehen.
 
-Stelle dir das Bearbeiten deines Codes oder deiner Dokumente wie ein
-Computerspiel vor. Wenn du gut voran gekommen bist, willst du das Erreichte
-sichern. Um das zu tun, klickst du auf auf Speichern in deinem vertrauten
+Stelle Dir das Bearbeiten deines Codes oder Deiner Dokumente wie ein
+Computerspiel vor. Wenn Du gut vorangekommen bist, willst Du das Erreichte
+sichern. Um das zu tun, klickst Du auf auf Speichern in Deinem vertrauten
 Editor.
 
 Aber, das überschreibt die vorherige Version. Das ist wie bei den Spielen
 der alten Schule, die nur Speicherplatz für eine Sicherung hatten:
-sicherlich konntest du speichern, aber du konntest nie zu einem älteren
-Stand zurück. Das war eine Schande, denn vielleicht war deine vorherige
-Sicherung an einer außergewöhnlich spannenden Stelle des Spiels, zu der du
-später gerne noch einmal zurückkehren möchtest. Oder noch schlimmer, deine
-aktuelle Sicherung ist in einem nicht lösbaren Stand, dann musst du von ganz
+sicherlich konntest Du speichern, aber Du konntest nie zu einem älteren
+Stand zurück. Das war eine Schande, denn vielleicht war Deine vorherige
+Sicherung an einer außergewöhnlich spannenden Stelle des Spiels, zu der Du
+später gerne noch einmal zurückkehren möchtest. Oder noch schlimmer, Deine
+aktuelle Sicherung ist in einem nicht lösbaren Stand, dann musst Du von ganz
 vorne beginnen.
 
 === Versionsverwaltung ===
 
-Beim Editieren kannst du deine Datei durch 'Speichern unter ...' mit einem
-neuen Namen abspeichern oder du kopierst sie vor dem Speichern irgendwo hin
-um die alte Version zu erhalten. Außerdem kannst du sie komprimieren um
+Beim Editieren kannst Du Deine Datei durch 'Speichern unter ...' mit einem
+neuen Namen abspeichern oder Du kopierst sie vor dem Speichern irgendwo hin,
+um die alte Version zu erhalten. Außerdem kannst Du sie komprimieren, um
 Speicherplatz zu sparen. Das ist eine primitive und mühselige Form der
 Versionsverwaltung. Computerspiele machten das lange Zeit so, viele von
 ihnen hatten automatisch erstellte Sicherungspunkte mit Zeitstempel.
 
-Jetzt lass uns das Problem etwas komplizierter machen. Sagen wir, du hast
+Jetzt lass uns das Problem etwas komplizierter machen. Sagen wir, Du hast
 einen Haufen Dateien, die zusammen gehören, z.B. Quellcodes für ein Projekt
-oder Dateien einer Website. Wenn du nun eine alte Version erhalten willst,
-musst du den ganzen Ordner archivieren. Viele Versionen auf diese Art zu
-archivieren ist mühselig und kann sehr schnell teuer werden.
+oder Dateien einer Website. Wenn Du nun eine alte Version erhalten willst,
+musst Du den ganzen Ordner archivieren. Viele Versionen auf diese Art zu
+archivieren, ist mühselig und kann sehr schnell teuer werden.
 
 Bei einigen Computerspielen bestand ein gesicherter Stand wirklich aus einem
 Ordner voller Dateien. Diese Spiele versteckten die Details vor dem Spieler
-und präsentierten eine bequeme Oberfläche um verschiedene Versionen des
+und präsentierten eine bequeme Oberfläche, um verschiedene Versionen des
 Ordners zu verwalten.
 
 Versionsverwaltungen sind nicht anders. Sie alle haben bequeme
-Schnittstellen um Ordner voller Dateien zu verwalten. Du kannst den Zustand
-des Ordners sichern so oft du willst und du kannst später jeden
+Schnittstellen, um Ordner voller Dateien zu verwalten. Du kannst den Zustand
+des Ordners sichern, so oft Du willst, und du kannst später jeden
 Sicherungspunkt wieder herstellen. Im Gegensatz zu den meisten
-Computerspielen sind sie aber in der Regel dafür ausgelegt sparsam mit dem
+Computerspielen sind sie aber in der Regel dafür ausgelegt, sparsam mit dem
 Speicherplatz umzugehen. Normalerweise ändern sich immer nur wenige Dateien
-zwischen zwei Versionen und die Änderungen selbst sind oft nicht groß. Die
+zwischen zwei Versionen, und die Änderungen selbst sind oft nicht groß. Die
 Platzersparnis beruht auf dem Speichern der Unterschiede an Stelle einer
 Kopie der ganzen Datei.
 
 === Verteilte Kontrolle ===
 
-Nun stell dir ein ganz kompliziertes Computerspiel vor. So schwierig zu
-lösen, dass viele erfahrene Spieler auf der ganzen Welt beschließen sich
-zusammen zu tun und ihre gespeicherten Spielstände auszutauschen um das
+Nun stell Dir ein ganz kompliziertes Computerspiel vor. So schwierig zu
+lösen, dass viele erfahrene Spieler auf der ganzen Welt beschließen, sich
+zusammen zu tun und ihre gespeicherten Spielstände auszutauschen, um das
 Spiel zu beenden. 'Speedruns' sind Beispiele aus dem echten Leben: Spieler,
 die sich in unterschiedlichen Spielebenen des selben Spiels spezialisiert
-haben, arbeiten zusammen um erstaunliche Ergebnisse zu erzielen.
+haben, arbeiten zusammen, um erstaunliche Ergebnisse zu erzielen.
 
-Wie würdest du ein System erstellen, bei dem jeder auf einfache Weise die
+Wie würdest Du ein System erstellen, bei dem jeder auf einfache Weise die
 Sicherungen der anderen bekommt? Und eigene Sicherungen bereitstellt?
 
 Früher nutzte jedes Projekt eine zentralisierte Versionsverwaltung. Irgendwo
@@ -77,12 +77,12 @@ wieder auf den Server laden, damit irgendjemand ihn nutzen kann.
 
 Was, wenn ein Spieler aus irgendeinem Grund einen alten Spielstand will?
 Vielleicht ist der aktuell gesicherte Spielstand nicht mehr lösbar, weil
-jemand in der dritten Ebene vergessen hat ein Objekt aufzunehmen und sie
-versuchen den letzten Spielstand zu finden, ab dem das Spiel wieder lösbar
-ist. Oder sie wollen zwei Spielstände vergleichen, um festzustellen wie viel
+jemand in der dritten Ebene vergessen hat, ein Objekt aufzunehmen und sie
+versuchen, den letzten Spielstand zu finden, ab dem das Spiel wieder lösbar
+ist. Oder sie wollen zwei Spielstände vergleichen, um festzustellen, wie viel
 ein Spieler geleistet hat.
 
-Es gibt viele Gründe warum man einen älteren Stand sehen will, aber das
+Es gibt viele Gründe, warum man einen älteren Stand sehen will, aber das
 Ergebnis ist das selbe. Man muss vom Hauptserver das alte gespeicherte Spiel
 anfordern. Je mehr gespeicherte Spiele benötigt werden, desto mehr
 Kommunikation ist erforderlich.
@@ -91,7 +91,7 @@ Die neue Generation der Versionsverwaltungssysteme, zu denen Git gehört,
 werden verteilte Systeme genannt und können als eine Verallgemeinerung der
 zentralisierten Systeme verstanden werden. Wenn Spieler vom Hauptserver
 herunterladen, erhalten sie jedes gespeichertes Spiel, nicht nur das zuletzt
-gespeicherte. Es ist als ob der Hauptserver gespiegelt wird.
+gespeicherte. Es ist, als ob der Hauptserver gespiegelt wird.
 
 Dieses erste 'Cloning' kann teuer sein, vor allem, wenn eine lange
 Geschichte existiert, aber auf Dauer wird es sich lohnen. Ein unmittelbarer
@@ -103,10 +103,10 @@ keine Kommunikation mit dem Hauptserver notwendig.
 Ein weit verbreitetes Missverständnis ist, dass verteilte System ungeeignet
 sind für Projekte, die ein offizielles zentrales 'Repository'
 benötigen. Nichts könnte weiter von der Wahrheit entfernt sein. Jemanden zu
-fotografieren stiehlt nicht dessen Seele. Genauso wenig setzt das 'Clonen'
+fotografieren, stiehlt nicht dessen Seele. Genauso wenig setzt das 'Clonen'
 des zentralen 'Repository' dessen Bedeutung herab.
 
-Eine gute erste Annäherung ist, dass alles was eine zentralisierte
+Eine gute erste Annäherung ist, dass alles, was eine zentralisierte
 Versionsverwaltung kann, ein gut durchdachtes verteiltes System besser
 kann. Netzwerkressourcen sind einfach teurer als lokale Ressourcen. Auch
 wenn wir später Nachteile beim verteilten Ansatz sehen werden, ist man mit
@@ -117,11 +117,11 @@ so ein System bietet. Aber deshalb ein einfacheres, schlecht erweiterbares
 System zu benutzen, ist wie römische Ziffern zum Rechnen mit kleinen Zahlen
 zu verwenden.
 
-Außerdem könnte dein Projekt weit über die ursprünglichen Erwartungen
+Außerdem könnte Dein Projekt weit über die ursprünglichen Erwartungen
 hinauswachsen. Git von Anfang an zu benutzen, ist wie ein Schweizer
 Taschenmesser mit sich zu tragen, auch wenn damit meistens nur Flaschen
-geöffnet werden. Eines Tages brauchst du vielleicht dringend einen
-Schraubendreher, dann bist du froh mehr als nur einen einfachen
+geöffnet werden. Eines Tages brauchst Du vielleicht dringend einen
+Schraubendreher, dann bist du froh, mehr als nur einen einfachen
 Flaschenöffner bei dir zu haben.
 
 === 'Merge' Konflikte ===
@@ -135,7 +135,7 @@ automatisch eine vernünftige Vorgehensweise: akzeptiere beide Änderungen und
 füge sie zusammen, damit fließen beide Änderungen in das Dokument mit ein.
 
 Nun stell dir vor beide, Alice und Bob, machen Änderungen in der selben
-Zeile. Dann ist es unmöglich ohne menschlichen Eingriff fortzufahren. Die
+Zeile. Dann ist es unmöglich, ohne menschlichen Eingriff fortzufahren. Die
 zweite Person, welche die Datei hoch lädt, wird über einen _'Merge'
 Konflikt_ informiert und muss entscheiden, welche Änderung übernommen wird
 oder die ganze Zeile überarbeiten. 

de/preface.txt

@@ -10,7 +10,7 @@ es schwierig zu erlernen macht, ganz zu schweigen davon, es zu meistern.
 Wie Arthur C. Clarke festgestellt hat, ist jede hinreichend fortschrittliche
 Technologie nicht von Magie zu unterscheiden. Das ist ein großartiger Ansatz, 
 um an Git heranzugehen: Anfänger können seine inneren Mechanismen ignorieren
-und Git als ein Ding ansehen, das mit seinen erstaunlichen Fähigkeiten
+und Git als ein Ding ansehen, dass mit seinen erstaunlichen Fähigkeiten
 Freunde verzückt und Gegner zur Weißglut bringt.
 
 Anstatt die Details aufzudecken, bieten wir grobe Anweisungen für die
@@ -69,7 +69,7 @@ François Marier unterhält das Debian Packet, das ursprünglich von Daniel
 Baumann erstellt wurde.
 
 Meine Dankbarkeit gilt auch vielen anderen für deren Unterstützung und
-Lob. Ich war versucht, euch hier alle aufzuzählen, aber das könnte
+Lob. Ich war versucht, Euch hier alle aufzuzählen, aber das könnte
 Erwartungen in unermesslichem Umfang wecken.
 
 Wenn ich Dich versehentlich vergessen habe, sag' mir bitte Bescheid oder