Merge pull request #117 from Mo-Gul/corrections-ch02

Korrekturen zu Kapitel 2

Author: max123kl

C-git-commands.asc

@@ -152,7 +152,7 @@ Im Buch wird so ziemlich alles angesprochen, was man mit dem Befehl `git status`
 ==== git diff
 
 Der `git diff` Befehl wird verwendet, wenn Sie Unterschiede zwischen zwei beliebigen Bäumen feststellen möchten.
-Das könnte der Unterschied zwischen Ihrer Arbeitsumgebung und Ihrer Staging Area (`git diff` an sich), zwischen Ihrer Staging Area und Ihrem letzten Commit (`git diff --staged`) oder zwischen zwei Commits (`git diff master branchB`) sein.
+Das könnte der Unterschied zwischen Ihrer Arbeitsumgebung und Ihrer Staging-Area (`git diff` an sich), zwischen Ihrer Staging-Area und Ihrem letzten Commit (`git diff --staged`) oder zwischen zwei Commits (`git diff master branchB`) sein.
 
 In <<ch02-git-basics-chapter#_git_diff_staged>> betrachten wir zunächst die grundsätzliche Anwendung von `git diff` und zeigen dort, wie man feststellen kann, welche Änderungen bereits der Staging-Area hinzugefügt wurden und welche noch nicht.
 
@@ -172,7 +172,7 @@ Das erwähnen wir nur kurz in <<ch02-git-basics-chapter#_git_diff_staged>>.
 
 ==== git commit
 
-Der `git commit` Befehl erfasst alle Dateiinhalte, die mit `git add` zur Staging Area hinzugefügt wurden und speichert einen neuen permanenten Schnappschuss in der Datenbank. Anschließend bewegt er den Branch-Pointer der aktuellen Branch zu diesem hinauf.
+Der `git commit` Befehl erfasst alle Dateiinhalte, die mit `git add` zur Staging-Area hinzugefügt wurden und speichert einen neuen permanenten Schnappschuss in der Datenbank. Anschließend bewegt er den Branch-Pointer der aktuellen Branch zu diesem hinauf.
 
 Wir erklären zunächst die Grundlagen des Commitings in <<ch02-git-basics-chapter#_committing_changes>>.
 Dort zeigen wir auch, wie man mit dem `-a` Flag den Schritt `git add` im täglichen Arbeitsablauf überspringt und wie man mit dem `-m` Flag eine Commit-Meldung in der Kommandozeile übergibt, anstatt einen Editor zu starten.
@@ -188,10 +188,10 @@ Schließlich werfen wir einen Blick darauf, was der Befehl `git commit` im Hinte
 ==== git reset
 
 Der `git reset` Befehl wird in erster Linie verwendet, um Aktionen rückgängig zu machen, wie man am Kommando erkennen kann.
-Er verschiebt den `HEAD` Pointer und ändert optional den `index` oder die Staging Area und kann optional auch das Arbeitsverzeichnis ändern, wenn Sie `--hard` verwenden.
+Er verschiebt den `HEAD` Pointer und ändert optional den `index` oder die Staging-Area und kann optional auch das Arbeitsverzeichnis ändern, wenn Sie `--hard` verwenden.
 Bei falscher Verwendung der letzten Option kann mit diesem Befehl auch Arbeit verloren gehen, vergewissern Sie sich daher, dass Sie ihn verstehen, bevor Sie ihn verwenden.
 
-Wir befassen uns zunächst mit der einfachsten Anwendung von `git reset` in <<ch02-git-basics-chapter#_unstaging>>. Dort benutzen wir es, um eine Datei, die wir mit `git add` hinzu gefügt haben, wieder aus der Staging Area zu entfernen.
+Wir befassen uns zunächst mit der einfachsten Anwendung von `git reset` in <<ch02-git-basics-chapter#_unstaging>>. Dort benutzen wir es, um eine Datei, die wir mit `git add` hinzu gefügt haben, wieder aus der Staging-Area zu entfernen.
 
 Wir gehen dann in <<ch07-git-tools#_git_reset>> detailliert auf diesen Befehl ein, der sich ganz der Beschreibung dieses Befehls widmet.
 
@@ -202,7 +202,7 @@ Wir verwenden `git reset --hard`, um einen Merge in <<ch07-git-tools#_abort_merg
 Der `git rm` Befehl wird verwendet, um Dateien aus dem Staging-Bereich und dem Arbeitsverzeichnis von Git zu entfernen.
 Er ähnelt `git add` dahingehend, dass er das Entfernen einer Datei für den nächsten Commit vorbereitet.
 
-Wir behandeln den Befehl `git rm` in <<ch02-git-basics-chapter#_removing_files>> ausführlich, einschließlich des rekursiven Entfernens von Dateien und des Entfernens von Dateien aus der Staging Area, wobei sie jedoch, mit `--cached`, im Arbeitsverzeichnis belassen werden.
+Wir behandeln den Befehl `git rm` in <<ch02-git-basics-chapter#_removing_files>> ausführlich, einschließlich des rekursiven Entfernens von Dateien und des Entfernens von Dateien aus der Staging-Area, wobei sie jedoch, mit `--cached`, im Arbeitsverzeichnis belassen werden.
 
 Die einzige andere abweichende Verwendung von `git rm` im Buch ist in <<ch10-git-internals#_removing_objects>> beschrieben, wo wir kurz die `--ignore-unmatch` beim Ausführen von `git filter-branch` verwenden und erklären, was es einfach nicht fehlerfrei macht, wenn die Datei, die wir zu entfernen versuchen, nicht existiert.
 Das kann bei der Erstellung von Skripten nützlich sein.

book/01-introduction/sections/what-is-git.asc

@@ -91,7 +91,7 @@ Der Verzeichnisbaum ist ein einzelner Abschnitt einer Version des Projekts.
 Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis geholt und auf der Festplatte so abgelegt, damit Sie sie verwenden oder ändern können.
 
 Die Staging-Area ist in der Regel eine Datei, die sich in Ihrem Git-Verzeichnis befindet und Informationen darüber speichert, was in Ihren nächsten Commit einfließen soll.
-Der technische Name im Git-Sprachgebrauch ist „Index“, aber der Ausdruck „Staging Area“ funktioniert genauso gut.
+Der technische Name im Git-Sprachgebrauch ist „Index“, aber der Ausdruck „Staging-Area“ funktioniert genauso gut.
 
 Im Git-Verzeichnis werden die Metadaten und die Objektdatenbank für Ihr Projekt gespeichert.
 Das ist der wichtigste Teil von Git, dieser Teil wird kopiert, wenn man ein Repository von einem anderen Rechner _klont_.

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

@@ -3,10 +3,10 @@
 
 (((Aliasnamen)))
 Bevor wir dieses Kapitel über Basic Git abschließen, gibt es noch einen kurzen Tipp, der Ihre Arbeit mit Git einfacher, leichter und verständlicher machen kann: Aliase.
-Wir werden nicht auf sie Bezug nehmen oder annehmen, dass Sie sie später im Buch verwenden, aber Sie sollten wohl wissen, wie man sie benutzt.
+Der Klarheit halber werden wir sie nirgendwo anders in diesem Buch verwenden, aber wenn Sie Git in Zukunft mit einiger Regelmäßigkeit verwenden, sind Aliase etwas, das Sie kennen sollten.
 
-Git leitet Ihr Kommando nicht automatisch ab, wenn Sie es teilweise eingeben.
-Wenn Sie nicht den gesamten Text von jedem der Git-Befehle eingeben möchten, können Sie mit Hilfe von `git config` einfach einen Alias für jeden Befehl einrichten.(((Git Befehle, config)))
+Git schließt nicht automatisch auf Ihren Befehl, wenn Sie ihn nur teilweise eingeben.
+Wenn Sie nicht den gesamten Text von jedem der Git-Befehle eingeben möchten, können Sie mit Hilfe von `git config` einfach ein Alias für jeden Befehl einrichten.(((Git Befehle, config)))
 Hier sind ein paar Beispiele, die Sie einrichten sollten:
 
 [source,console]
@@ -17,11 +17,11 @@ $ git config --global alias.ci commit
 $ git config --global alias.st status
 ----
 
-Das bedeutet, dass Sie z.B. anstelle von `git commit` einfach `git ci` eingeben müssen.
+Das bedeutet, dass Sie z.B. anstelle von `git commit` einfach `git ci` eingeben können.
 Wenn Sie Git nun weiter verwenden, werden Sie vermutlich auch andere Befehle häufig verwenden; scheuen Sie sich nicht, neue Aliase zu erstellen.
 
 Diese Technik kann auch sehr nützlich sein, um Befehle zu erstellen, von denen Sie glauben, dass sie vorhanden sein sollten.
-Um beispielsweise ein Usability-Problem zu beheben, auf das Sie beim Entfernen einer Datei aus der Staging Area stoßen, können Sie Git Ihren eigenen Unstage-Alias hinzufügen:
+Um beispielsweise ein Usability-Problem zu beheben, auf das Sie beim Entfernen einer Datei aus der Staging-Area stoßen, können Sie Git Ihren eigenen Unstage-Alias hinzufügen:
 
 [source,console]
 ----
@@ -60,9 +60,9 @@ Date:   Tue Aug 26 19:48:51 2008 +0800
 
 Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alias, für den Sie ihn verwenden.
 Vielleicht möchten Sie jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen.
-In diesem Fall starten Sie den Befehl mit einem `!` Zeichen.
+In diesem Fall starten Sie den Befehl mit einem `!`-Zeichen.
 Das ist hilfreich, wenn Sie Ihre eigenen Tools schreiben, die mit einem Git-Repository arbeiten.
-Wir können durch Aliasing von  `git visual` demonstrieren, um `gitk` auszuführen:
+Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasieren:
 
 [source,console]
 ----

book/02-git-basics/sections/getting-a-repository.asc

@@ -1,7 +1,7 @@
 [[_getting_a_repo]]
-=== Ein Git Repository anlegen
+=== Ein Git-Repository anlegen
 
-Sie haben zwei Möglichkeiten, ein Git Repository auf Ihrem Rechner anzulegen.
+Sie haben zwei Möglichkeiten, ein Git-Repository auf Ihrem Rechner anzulegen.
 
 1. Sie können ein lokales Verzeichnis, das sich derzeit nicht unter Versionskontrolle befindet, in ein Git-Repository verwandeln, oder
 2. Sie können ein bestehendes Git-Repository von einem anderen Ort aus _klonen_.
@@ -29,16 +29,16 @@ für Windows:
 $ cd C:/Users/user/my_project
 ----
 
-dann folgenden Befehl eingeben:
+und tragen Sie dort folgenden Befehl ein:
 
 [source,console]
 ----
 $ git init
 ----
 
-Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git Repository Daten enthalten sind, also ein Git Repository Grundgerüst.
+Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git-Repository-Daten enthalten sind, also ein Git-Repository Grundgerüst.
 Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert.
-(In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Interna>>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.)(((Git Befehle, init)))
+(In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Interna>>, finden Sie weitere Informationen, welche Dateien im `.git`-Verzeichnis enthalten sind und was ihre Aufgabe ist.)(((Git Befehle, init)))
 
 Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit starten.
 Mit dem Befehl `git add` legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugen Sie einen neuen Commit:
@@ -51,27 +51,27 @@ $ git commit -m 'Initial project version'
 ----
 
 Wir werden gleich noch einmal genauer auf diese Befehle eingehen.
-Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git Repository erzeugt und einen ersten Commit angelegt haben.
+Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git-Repository erzeugt und einen ersten Commit angelegt haben.
 
 [[_git_cloning]]
 ==== Ein existierendes Repository klonen
 
-Wenn Sie eine Kopie eines existierenden Git Repositorys anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden.
-Wenn Sie bereits Erfahrung mit einem anderen VCS System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet.
-Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten – Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner.
+Wenn Sie eine Kopie eines existierenden Git-Repositorys anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden.
+Wenn Sie bereits Erfahrung mit einem anderen VCS-System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet.
+Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten. Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner.
 Jede Version von jeder Datei der Projekt-Historie wird automatisch heruntergeladen, wenn Sie `git clone` ausführen.
-Wenn Ihre Serverfestplatte beschädigt wird, können Sie oft nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden – siehe Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, für weitere Details).
+Wenn Ihre Serverfestplatte beschädigt wird, können Sie oft nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand. (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden – siehe Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, für weitere Details.)
 
 Sie können ein Repository mit dem Befehl `git clone [url]` klonen.(((Git Befehle, clone)))
-Um beispielsweise das Repository der verlinkbaren Git Bibliothek `libgit2` zu klonen, führen Sie den folgenden Befehl aus:
+Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu klonen, führen Sie den folgenden Befehl aus:
 
 [source,console]
 ----
 $ git clone https://github.com/libgit2/libgit2
 ----
 
-Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter, und checkt eine Arbeitskopie der aktuellsten Version aus.
-Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten.
+Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git`-Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Arbeitskopie der aktuellsten Version aus.
+Wenn Sie in das neue `libgit2`-Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten.
 
 Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchten, können Sie das wie folgt durchführen:
 
@@ -80,8 +80,8 @@ Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2`
 $ git clone https://github.com/libgit2/libgit2 mylibgit
 ----
 
-Dieser Befehl tut das gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal `mylibgit`.
+Dieser Befehl tut das Gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal `mylibgit`.
 
 Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle.
-Das vorhergehende Beispiel verwendet das `https://` Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet.
+Das vorhergehende Beispiel verwendet das `https://`-Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet.
 Kapitel 4, <<ch04-git-on-the-server#_getting_git_on_a_server,Git auf dem Server>>, stellt alle verfügbaren Optionen vor, die der Server für den Zugriff auf Ihr Git-Repository hat und die Vor- und Nachteile der einzelnen Optionen, die man einrichten kann.