03 git branching diffs

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

@@ -5,6 +5,7 @@ Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schn
 
 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.
+Kurz gesagt, nachverfolgte Dateien sind Dateien, die Git kennt.
 
 Alle anderen Dateien in Ihrem Arbeitsverzeichnis dagegen, sind nicht versioniert: das sind all diejenigen Dateien, die nicht schon im letzten Schnappschuss enthalten waren und die sich nicht in der Staging-Area befinden.
 Wenn Sie ein Repository zum ersten Mal klonen, sind alle Dateien versioniert und unverändert. Nach dem Klonen wurden sie ja ausgecheckt und bis dahin haben Sie auch noch nichts an ihnen verändert.
@@ -40,6 +41,7 @@ Wir werden im Kapitel <<ch03-git-branching#ch03-git-branching,Git Branching>> au
 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.
 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.
 ====
 

book/03-git-branching/sections/branch-management.asc

@@ -179,4 +179,4 @@ Nachdem Sie alle diese Aufgaben erledigt haben und sicher sind, dass der `main`
 [source, console]
 ----
 $ git push origin --delete master
-----
+----

book/03-git-branching/sections/nutshell.asc

@@ -206,4 +206,4 @@ Ab Git version 2.23 können sie `git switch` anstatt von `git checkout` nutzen u
 - Zu einem bestehendem Branch wechseln mit: `git switch testing-branch`.
 - Einen neuen Branch erstellen und zu ihm wechseln mit: `git switch -c new-branch`. Die `-c` Option steht für Create (Anlegen), sie können auch die komplette Option `--create` nutzen.
 - Zurück zu ihrem zuletzt ausgechecktem Branch wechseln mit: `git switch -`.
-====
+====

book/03-git-branching/sections/rebasing.asc

@@ -227,6 +227,7 @@ Aus diesem Blickwinkel ist das Ändern der Commit-Historie fast blasphemisch. Ma
 Was wäre, wenn es eine verwirrende Reihe von Merge-Commits gäbe?
 So ist es nun mal passiert, und das Repository sollte das beibehalten.
 
+Der entgegengesetzte Standpunkt ist, dass der Commit-Verlauf die *Geschichte wie Ihr Projekt erstellt wurde.* darstellt.
 Sie würden den ersten Entwurf eines Buches nicht veröffentlichen. Warum also Ihre unordentliche Arbeit zeigen?
 Wenn Sie an einem Projekt arbeiten, benötigen Sie möglicherweise eine Aufzeichnung all Ihrer Fehltritte und Sackgassen. Wenn es jedoch an der Zeit ist, Ihre Arbeit der Welt zu zeigen, möchten Sie möglicherweise eine kohärentere Geschichte darüber erzählen, wie Sie von A nach B gekommen sind.
 Die Leute in diesem Camp verwenden Tools wie Rebase und Filter-Branch, um ihre Commits neu zu schreiben, bevor sie in den Mainline-Branch integriert werden.