kapitel zwei review

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

@@ -5,8 +5,8 @@
 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.
 Der Klarheit halber werden wir sie nirgendwo anders in diesem Buch verwenden, aber wenn Sie Git in Zukunft regelmäßig verwenden, dann sind Aliase etwas, das Sie kennen sollten.
 
-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)))
+Git erkennt nicht automatisch Ihren abgesetzten Befehl, wenn Sie ihn nur teilweise eingeben.
+Wenn Sie nicht den gesamten Text jedes Git-Befehls 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]
@@ -36,7 +36,7 @@ $ git unstage fileA
 $ git reset HEAD -- fileA
 ----
 
-Das erscheint etwas klarer.
+Das macht denn Sinn des aliasing hoffentlich klarer.
 Es ist auch üblich, einen `last` (dt. letzten) Befehl hinzuzufügen, so wie hier:
 
 [source,console]
@@ -62,7 +62,7 @@ Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alia
 Vielleicht möchten Sie jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen.
 In diesem Fall starten Sie den Befehl mit einem Ausrufezeichen (`!`).
 Das ist hilfreich, wenn Sie Ihre eigenen Tools schreiben, die mit einem Git-Repository arbeiten.
-Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasieren:
+Hier ein Beispiel, in dem wir `git visual` mit `gitk` aliasen:
 
 [source,console]
 ----

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

@@ -60,7 +60,7 @@ Wenn Sie eine Kopie eines existierenden Git-Repositorys anlegen wollen – um be
 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 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 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 versionierte 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:
@@ -84,4 +84,4 @@ Dieser Befehl tut das Gleiche wie der vorhergehende, aber das Zielverzeichnis la
 
 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.
-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.
+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 möglichen Optionen.

book/02-git-basics/sections/recording-changes.asc

@@ -1,7 +1,7 @@
 === Änderungen nachverfolgen und im Repository speichern
 
-An dieser Stelle sollten Sie ein _originalgetreues_ Git-Repository auf Ihrem lokalen Computer und eine Checkout- oder Arbeitskopie aller seiner Dateien vor sich haben.
-Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in Ihr Repository zu übertragen, wenn das Projekt so weit fortgeschritten ist, dass Sie es sichern möchten.
+An dieser Stelle sollten Sie ein _angemessenes_ Git-Repository auf Ihrem lokalen Computer und eine Checkout- oder Arbeitskopie aller seiner Dateien vor sich haben.
+Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in Ihr Repository zu committen, wenn das Projekt so weit fortgeschritten ist, dass Sie es sichern möchten.
 
 Denken Sie daran, dass sich jede Datei in Ihrem Arbeitsverzeichnis in einem von zwei Zuständen befinden kann: _tracked_ oder _untracked_ – Änderungen an der Datei werden verfolgt (engl. _tracked_) oder eben nicht (engl. _untracked_).
 Tracked Dateien sind Dateien, die im letzten Snapshot enthalten sind. Genauso wie alle neuen Dateien in der Staging-Area. Sie können entweder unverändert, modifiziert oder für den nächsten Commit vorgemerkt (staged) sein.
@@ -39,10 +39,10 @@ Wir werden im Kapitel <<ch03-git-branching#ch03-git-branching,Git Branching>> au
 [NOTE]
 ====
 GitHub änderte Mitte 2020 den Standard-Branch-Namen von `master` in `main`, und andere Git-Hosts folgten diesem Beispiel.
-Daher werden Sie möglicherweise feststellen, dass der Standard-Branch-Name in einigen neu erstellten Repositories `main` und nicht `master` ist.
+Daher werden Sie möglicherweise feststellen, dass der Standard-Branch-Name in einigen neu erstellten Repositorys `main` und nicht `master` ist.
 Außerdem kann der Standard-Branch-Name geändert werden (wie Sie in <<ch01-getting-started#_new_default_branch>> gesehen haben), sodass Sie möglicherweise einen anderen Namen für den Standard-Branch vorfinden.
 
-Git selbst verwendet jedoch immer noch `master` als Standard, also werden wir auch es im gesamten Buch verwenden.
+Git selbst verwendet jedoch immer noch `master` als Standard, also werden wir es auch im gesamten Buch verwenden.
 ====
 
 Nehmen wir einmal an, Sie fügen eine neue Datei mit dem Namen `README` zu Ihrem Projekt hinzu.
@@ -582,7 +582,7 @@ Oder Sie können Folgendes ausführen:
 $ git rm \*~
 ----
 
-Dieses Kommando entfernt alle Dateien, deren Name mit einer `~` endet.
+Dieses Kommando entfernt alle Dateien, deren Name mit `~` endet.
 
 [[_git_mv]]
 ==== Dateien verschieben

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

@@ -1,7 +1,7 @@
 [[_remote_repos]]
 === Mit Remotes arbeiten
 
-Um an jedem Git-Projekt mitarbeiten zu können, müssen Sie wissen, wie Sie Ihre Remote-Repositorys verwalten können.
+Um an Git-Projekte mitarbeiten zu können, müssen Sie wissen, wie Sie Remote-Repositorys verwalten können.
 Remote-Repositorys sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden.
 Sie können mehrere einrichten, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar für Sie ist.
 Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn Sie Ihre Arbeit teilen möchten.
@@ -36,7 +36,7 @@ $ git remote
 origin
 ----
 
-Sie können zusätzlich auch `-v` angeben, das Ihnen die URLs anzeigt, die Git für den Kurznamen gespeichert hat, der beim Lesen und Schreiben auf diesem Remote verwendet werden soll:
+Sie können zusätzlich auch `-v` angeben, das Ihnen die URLs anzeigt, die Git für den Kurznamen gespeichert hat, um beim Lesen und Schreiben auf diesen Remote zuzugreifen:
 
 [source,console]
 ----
@@ -72,7 +72,7 @@ Beachten Sie, dass diese Remotes eine Vielzahl von Protokollen verwenden; wir we
 ==== Hinzufügen von Remote-Repositorys
 
 Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl `git clone` stillschweigend den Remote `origin` für Sie hinzufügt.
-So können Sie explizit einen neuen Remote hinzufügen.(((Git Befehle, remote)))
+Im Folgendem beschreiben wir, wie Sie einen neuen Remote hinzufügen können.(((Git Befehle, remote)))
 Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das Sie leicht verweisen können, führen Sie `git remote add <shortname> <url>` aus:
 
 [source,console]
@@ -87,8 +87,8 @@ pb	https://github.com/paulboone/ticgit (fetch)
 pb	https://github.com/paulboone/ticgit (push)
 ----
 
-Jetzt können Sie die Zeichenfolge `pb` auf der Kommandozeile anstelle der gesamten URL verwenden.
-Wenn Sie beispielsweise alle Informationen abrufen möchten, die Paul hat, die aber noch nicht in Ihrem Repository enthalten sind, können Sie `git fetch pb` ausführen:
+Nun können Sie die Zeichenfolge `pb` auf der Kommandozeile anstelle der gesamten URL verwenden.
+Wenn Sie beispielsweise alle Informationen fetchen möchten, die Paul hat, die aber noch nicht in Ihrem Repository enthalten sind, können Sie `git fetch pb` ausführen:
 
 [source,console]
 ----
@@ -115,17 +115,17 @@ Wie Sie gerade gesehen haben, können Sie Daten aus Ihren Remote-Projekten abruf
 $ git fetch <remote>
 ----
 
-Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt runter, die Sie noch nicht haben.
+Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt, die Sie noch nicht haben.
 Danach sollten Sie Referenzen auf alle Branches von diesem Remote haben, die Sie jederzeit einbinden oder inspizieren können.
 
 Wenn Sie ein Repository klonen, fügt der Befehl dieses entfernte Repository automatisch unter dem Namen „origin“ hinzu.
-So holt `git fetch origin` alle neuen Inhalte, die seit dem Klonen (oder dem letzten Abholen) auf diesen Server verschoben wurden.
-Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in Ihr lokales Repository herunterlädt – er mischt (engl. merged) sie nicht automatisch mit Ihrer Arbeit zusammen oder ändert das, woran Sie gerade arbeiten.
+So holt `git fetch origin` alle Änderungen, die seit dem Klonen (oder dem letzten Abholen) auf diesen Server abgelegt (engl. pushed) wurden.
+Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in Ihr lokales Repository herunterlädt – er merged sie nicht automatisch mit Ihrer Arbeit zusammen oder ändert das, woran Sie gerade arbeiten.
 Sie müssen das Ganze manuell mit Ihrer Arbeit zusammenführen, wenn Sie fertig sind.
 
 Wenn Ihr aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), können Sie den Befehl `git pull` verwenden, um diesen entfernten Branch automatisch zu holen und dann mit Ihrem aktuellen Branch zusammenzuführen (siehe den nächsten Abschnitt und <<ch03-git-branching#ch03-git-branching,Git Branching>> für weitere Informationen).(((Git Befehle, pull)))
 Das könnte ein einfacherer oder komfortablerer Workflow für Sie sein. Standardmäßig richtet der Befehl `git clone` Ihren lokalen `master` Branch automatisch so ein, dass er den entfernten `master` Branch (oder wie auch immer der Standard-Branch genannt wird) auf dem Server versioniert von dem Sie ihn geklont haben.
-Wenn Sie `git pull` ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben, und es wird automatisch versucht in den Code zu mergen, an dem Sie gerade arbeiten.
+Wenn Sie `git pull` ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben. Anschliessend wird automatisch versucht diese Daten in ihren Code zu mergen.
 
 [NOTE]
 ====
@@ -142,9 +142,9 @@ Wenn Sie mit dem Pullen einen Rebase machen wollen:
 [[_pushing_remotes]]
 ==== Zu Ihren Remotes Pushen
 
-Wenn Sie Ihr Projekt an einem bestimmten Punkt haben, den Sie teilen möchten, müssen Sie es zum Upstream verschieben (engl. pushen).
-Der Befehl dafür ist einfach: `git push <remote> <branch>`.(((Git Befehle, push)))
-Wenn Sie Ihren `master` Branch auf Ihren `origin` Server verschieben möchten (nochmals, das Klonen richtet im Regelfall beide dieser Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen:
+Wenn Sie Ihr Projekt an einem Punkt haben, den Sie teilen möchten, können Sie es zum Upstream verschieben (engl. pushen).
+Der Befehl dafür lautet: `git push <remote> <branch>`.(((Git Befehle, push)))
+Wenn Sie Ihren `master` Branch auf Ihren `origin` Server verschieben möchten (Zur Erinnerung: das Klonen richtet im Regelfall diese beiden Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen:
 
 [source,console]
 ----
@@ -160,7 +160,7 @@ Siehe Kapitel 3 <<ch03-git-branching#ch03-git-branching,Git Branching>> mit ausf
 ==== Inspizieren eines Remotes
 
 Wenn Sie mehr Informationen über einen bestimmten Remote sehen möchten, können Sie den Befehl `git remote show <remote>` verwenden.(((Git Befehle, remote)))
-Wenn Sie diesen Befehl mit einem spezifischen Kurznamen ausführen, wie z.B. `origin`, erhalten Sie eine ähnliche Meldung:
+Wenn Sie diesen Befehl mit einem remote Kurznamen ausführen, wie z.B. `origin`, erhalten Sie bspw. folgende Meldung:
 
 [source,console]
 ----
@@ -178,12 +178,12 @@ $ git remote show origin
     master pushes to master (up to date)
 ----
 
-Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branchen auf.
-Der Befehl teilt Ihnen hilfreich mit, dass, wenn Sie sich im Master-Zweig befinden und `git pull` ausführen, der `master` Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird.
+Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branches auf.
+Der Befehl teilt Ihnen mit, dass, wenn Sie sich im Master-Zweig befinden und `git pull` ausführen, der `master` Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird.
 Er listet auch alle Remote-Referenzen auf, die er abgerufen hat.
 
-Das ist nur ein einfaches Beispiel, auf das Sie vermutlich treffen werden.
-Wenn Sie Git hingegen intensiver verwenden, können Sie viel mehr Informationen aus `git remote show` herauslesen:
+Das ist nur ein einfaches Beispiel, auf das Sie möglicherweise treffen werden.
+Wenn Sie Git hingegen intensiver verwenden, können die `git remote show` Ausgabe wesentlich umfangreicher sein:
 
 [source,console]
 ----
@@ -210,7 +210,7 @@ $ git remote show origin
 ----
 
 Dieser Befehl zeigt an, zu welchem Zweig automatisch gepusht wird, wenn Sie `git push` ausführen, während Sie sich in bestimmten Branches befinden.
-Er zeigt Ihnen auch, welche entfernten Branches auf dem Server sind, die Sie noch nicht haben, welche entfernten Branches Sie haben, die aber vom Server entfernt wurden und die lokalen Branches, die automatisch mit Ihrem Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn Sie `git pull` ausführen.
+Er zeigt Ihnen auch, welche entfernten Branches auf dem Server vorhanden sind, die Sie noch nicht haben, welche entfernten Branches Sie haben, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit Ihrem Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn Sie `git pull` ausführen.
 
 ==== Umbenennen und Entfernen von Remotes
 
@@ -226,7 +226,7 @@ paul
 ----
 
 Es ist zu beachten, dass dadurch auch alle Ihre Remote-Tracking-Branchnamen geändert werden.
-Was früher mit `pb/master` angesprochen wurde, ist jetzt `paul/master`.
+Was vorher unter `pb/master` referenziert wurde, ist jetzt unter `paul/master` zu finden.
 
 Wenn Sie einen Remote aus irgendwelchen Gründen entfernen möchten – Sie haben den Server verschoben oder verwenden einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann können Sie entweder `git remote remove` oder `git remote rm` verwenden: