Kapitel 3 review (#358)

Co-authored-by: Oscar Santiago <[email protected]>

Author: pastatopf

TRANSLATION_NOTES_DE.asc

@@ -65,6 +65,10 @@ Bitte erfinden Sie keine neue deutsche Übersetzung, sondern orientieren Sie sic
 [width="100%", frame="topbot", options="header,footer"]
 |==============================================================================
 |Englisch|Deutsch
+|to amend|
+amenden; er/sie amendet; wir amenden; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung revidieren verwendet werden.
+|ancestor|
+Vorgänger; Singular: der Vorgänger; Plural: die Vorgänger
 |to apply|
 anwenden
 |Branch|
@@ -111,6 +115,8 @@ forken; er/sie forkt; wir forken; Vorzugsweise die englische Version nutzen, alt
 Fork; Singular: der Fork; Plural: die Fork; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Abspaltung' verwendet werden je nach Kontext
 |HEAD|
 HEAD; Singular: der HEAD; Plural: die HEADs; Oft kann HEAD ohne Artikel verwendet werden
+|History|
+Historie; Singular: die Historie; Plural: die Historien
 |Issue|
 Problem
 |Index|
@@ -178,15 +184,17 @@ stagen; er/sie stagt; wir stagen; Deutsch zum Commit vormerken; zur Staging-Area
 |Staging area|
 Staging-Area; Alternativ: Index
 |stash|
-Stash; Singular: der Stash; Plural: die Stashes
+Stash; Singular: der Stash; Plural: die Stashes; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „verstecken“ verwendet werden.
 |to stash|
 stashen; er/sie stasht; wir stashen; Deutsch: zum Stash hinzufügen, auch bunkern (ev. mit Hinweis: engl. stashed, je nach Kontext)
 |String|
 String; Singular: der String; Plural: die Strings; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Zeichenkette“ verwendet werden.
 |Topic|
-Thema; Singular: das Thema; Plural: die Themen
+Thema; Singular: das Thema; Plural: die Themen;
+|Topic Branches|
+Feature-Branch; Singular: der Feature-Branch; Plural: die Feature-Branches;
 |to track|
-track; er/sie trackt; wir tracken; Deutsch: versionieren; Zur Versionsverwaltung hinzufügen, auch verfolgen (evtl. mit Hinweis: engl. tracked, je nach Kontext)
+track; er/sie trackt; wir tracken; Deutsch: folgen; Zur Versionsverwaltung hinzufügen, auch versionieren (evtl. mit Hinweis: engl. track, je nach Kontext)
 |==============================================================================
 
 === U – Z

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -1,19 +1,19 @@
 === Einfaches Branching und Merging
 
 Lassen Sie uns ein einfaches Beispiel für das Verzweigen und Zusammenführen (engl. branching and merging) anschauen, wie es Ihnen in einem praxisnahen Workflow begegnen könnte.
-Führen Sie diese Schritte aus:
+Stellen sie sich vor, sie führen folgende Schritte aus:
 
-. Arbeiten Sie an einer Website
-. Erstellen Sie einen Branch für eine neue Anwendergeschichte, an der Sie gerade arbeiten
-. Erledigen Sie einige Arbeiten in diesem Branch
+. Sie arbeiten an einer Website
+. Sie erstellen einen Branch für eine neue Anwendergeschichte (engl. User Story), an der Sie gerade arbeiten
+. Sie erledigen Sie einige Arbeiten in diesem Branch
 
 In diesem Moment erhalten Sie einen Anruf, dass ein anderes Problem kritisch ist und Sie einen Hotfix benötigen.
-Dazu werden Sie folgendes machen:
+Dazu werden Sie folgendes tun:
 
-. Wechseln Sie zu Ihrem Produktions-Branch
-. Erstellen Sie einen Branch, um den Hotfix einzufügen
+. Sie wechseln zu Ihrem Produktions-Branch
+. Sie erstellen einen Branch, um den Hotfix einzufügen
 . Nachdem der Test abgeschlossen ist, mergen Sie den Hotfix-Branch und schieben ihn in den Produktions-Branch
-. Wechseln Sie zurück zu Ihrer ursprünglichen Anwenderstory und arbeiten Sie daran weiter
+. Sie wechseln zurück zu Ihrer ursprünglichen Anwenderstory und arbeiten daran weiter
 
 [[_basic_branching]]
 ==== Einfaches Branching
@@ -57,12 +57,12 @@ $ git commit -a -m 'Create new footer [issue 53]'
 image::images/basic-branching-3.png[Der `iss53` Branch hat sich bei Ihrer Arbeit vorwärts bewegt]
 
 Jetzt bekommen Sie einen Anruf, dass es ein Problem mit der Website gibt und Sie es umgehend beheben müssen.
-Bei Git müssen Sie Ihren Fix nicht zusammen mit den Änderungen bereitstellen, die Sie bereits an `iss53` vorgenommen haben, und Sie müssen auch keinen großen Aufwand damit betreiben, diese Änderungen rückgängig zu machen, bevor Sie daran arbeiten können, Ihren Fix auf das anzuwenden, was sich in der Produktionsumgebung befindet.
+Bei Git müssen Sie Ihren Fix nicht zusammen mit den Änderungen bereitstellen, die Sie bereits an `iss53` vorgenommen haben. Sie müssen auch keinen großen Aufwand betreiben, diese Änderungen rückgängig zu machen, bevor Sie an den neuen Hotfix arbeiten können, um die Produktionsumgebung zu fixen.
 Alles, was Sie machen müssen, ist, zu Ihrem vorherigen `master` Branch zu wechseln.
 
 Beachten Sie dabei, dass Git das Wechseln zu einem anderen Branch blockiert, falls Ihr Arbeitsverzeichnis oder Ihr Staging-Bereich nicht committete Modifikationen enthält, die Konflikte verursachen.
-Es ist am besten, einen sauberen Zustand des Arbeitsbereichs anzustreben, bevor Sie die Branches wechseln.
-Es gibt Möglichkeiten, das zu umgehen (nämlich das Verstecken/Stashen und Revidieren/Amending von Änderungen), die wir später in Kapitel 7 <<ch07-git-tools#_git_stashing,Git Stashing>> behandeln werden.
+Generell ist es am besten, einen sauberen Zustand des Arbeitsbereichs anzustreben, bevor Sie Branches wechseln.
+Es gibt Möglichkeiten, das zu umgehen (nämlich das Verstecken (engl. Stashen) und Revidieren (engl. Amending) von Änderungen), die wir später in Kapitel 7 <<ch07-git-tools#_git_stashing,Git Stashing>> behandeln werden.
 Lassen Sie uns vorerst annehmen, Sie haben für alle Ihre Änderungen Commits durchgeführt, sodass Sie zu Ihrem vorherigen `master` Branch wechseln können.
 
 [source,console]
@@ -138,8 +138,8 @@ $ git commit -a -m 'Finish the new footer [issue 53]'
 .Arbeiten an `iss53` fortsetzen
 image::images/basic-branching-6.png[Arbeiten an `iss53` fortsetzen]
 
-Es ist erwähnenswert, dass die Arbeit, die Sie in Ihrem `hotfix` Branch durchgeführt haben, nicht in den Dateien in Ihrem `iss53` Branch enthalten ist.
-Wenn Sie diese Änderungen übernehmen müssen, können Sie Ihrem `master` Branch in den `iss53` Branch einbinden, indem Sie `git merge master` ausführen oder Sie können warten, bis Sie sich später entscheiden, den `iss53` Branch wieder zurück nach `master` zu übernehmen (engl. pullen).
+Erwähnenswert ist, dass die Änderungen, die Sie in Ihrem `hotfix` Branch durchgeführt haben, nicht in den Dateien ihres `iss53` Branch enthalten sind.
+Wenn Sie diese Änderungen übernehmen wollen, können Sie Ihrem `master` Branch in den `iss53` Branch übernehmen, indem Sie `git merge master` ausführen. Sie können aber auch warten und sich später dazu entscheiden, den `iss53` Branch in `master` zu übernehmen (engl. pullen).
 
 [[_basic_merging]]
 ==== Einfaches Merging
@@ -162,7 +162,7 @@ index.html |    1 +
 Das sieht ein bisschen anders aus, als das Merging mit dem `hotfix` Branch, welches Sie zuvor gemacht haben.
 Hier hat sich der Entwicklungsverlauf an einem früheren Zustand geteilt.
 Da der Commit auf dem Branch, auf dem Sie sich gerade befinden, kein unmittelbarer Vorgänger des Branches ist, in den Sie mergen, muss Git einige Arbeiten erledigen.
-In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die die Branch-Spitzen und der gemeinsame Vorfahr der beiden zeigen.
+In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die die Branch-Spitzen und der gemeinsame Vorgänger der beiden zeigen.
 
 .Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden
 image::images/basic-merging-1.png[Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden]
@@ -231,7 +231,7 @@ Ihre Datei enthält einen Bereich, der in etwa so aussieht:
 >>>>>>> iss53:index.html
 ----
 
-Das bedeutet, die Version in `HEAD` (Ihres `master` Branches, denn der wurde per `checkout` aktiviert, als Sie den `Merge` gestartet haben) ist der obere Teil des Blocks (alles oberhalb von `=======`) und die Version aus dem `iss53` Branch sieht wie der darunter befindliche Teil aus.
+Das bedeutet, die Version in `HEAD` (das ist der aktuelle commit `master` Branches, denn der wurde per `checkout` aktiviert, als Sie den `Merge` gestartet haben) ist der obere Teil des Blocks (alles oberhalb von `=======`) und die Version aus dem `iss53` Branch ist in dem darunter befindliche Teil.
 Um den Konflikt zu lösen, müssen Sie sich entweder für einen der beiden Teile entscheiden oder Sie führen die Inhalte selbst zusammen.
 Sie können diesen Konflikt beispielsweise lösen, indem Sie den gesamten Block durch diesen ersetzen:
 

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

@@ -2,7 +2,7 @@
 === Branch-Management
 
 (((Branches, verwalten)))
-Nachdem Sie nun einige Branches erzeugt, zusammengeführt und gelöscht haben, lassen Sie uns jetzt einige Werkzeuge für das Branch-Management betrachten, die sich als sehr nützlich erweisen werden, wenn Sie erst einmal ständig Branches benutzen.
+Nachdem Sie nun einige Branches erzeugt, zusammengeführt und gelöscht haben, lassen Sie uns jetzt einige Werkzeuge für das Branch-Management betrachten, die sich als sehr nützlich erweisen werden, wenn Sie erst einmal Branches benutzen.
 
 Der Befehl `git branch` kann noch mehr, als Branches zu erzeugen und zu löschen.(((Git Befehle, branch)))
 Wenn Sie die Anweisung ohne Argumente ausführen, bekommen Sie eine einfache Auflistung Ihrer aktuellen Branches:
@@ -37,7 +37,7 @@ $ git branch --merged
 * master
 ----
 
-Da Sie den Branch `iss53` schon früher gemergt haben, sehen Sie ihn in Ihrer Liste.
+Da Sie den Branch `iss53` schon früher gemergt haben, sehen Sie ihn in dieser Liste.
 Branches auf dieser Liste ohne vorangestelltes `*` können für gewöhnlich einfach mit der Anweisung `git branch -d` gelöscht werden; Sie haben deren Änderungen bereits zu einem anderen Branch hinzugefügt, sodass Sie nichts verlieren würden.
 
 Um alle Branches zu sehen, welche Änderungen enthalten, die Sie noch nicht integriert haben, können Sie die Anweisung `git branch --no-merged` ausführen:
@@ -58,7 +58,7 @@ error: The branch 'testing' is not fully merged.
 If you are sure you want to delete it, run 'git branch -D testing'.
 ----
 
-Wenn Sie den Branch wirklich löschen und diese Bearbeitungen aufgeben wollen, können Sie dies mit der Option `-D` erzwingen, wie die hilfreiche Meldung darauf hinweist.
+Wenn Sie den Branch wirklich löschen und diese Bearbeitungen aufgeben wollen, können Sie dies mit der Option `-D` erzwingen, worauf git in seinem Output hinweist.
 
 [TIP]
 ====
@@ -128,7 +128,7 @@ Nun ist der falsche Branchname vollständig durch den korrigierten Branchnamen e
 [WARNING]
 ====
 Wenn Sie den Namen eines Branches wie master/main/mainline/default ändern, werden die Integrationen, Dienste, Hilfsprogramme und Build/Release-Skripte, die Ihr Repository verwendet, höchstwahrscheinlich nicht mehr funktionieren.
-Bevor Sie dies tun, sollten Sie dies gründlich mit Ihren Mitstreitern beraten.
+Bevor Sie dies tun, sollten Sie dies gründlich mit Ihren Mitstreitern besprechen.
 Stellen Sie außerdem sicher, dass Sie Ihr Repo gründlich durchsuchen und alle Verweise auf den alten Branchnamen in Ihrem Code und in Ihren Skripten aktualisieren.
 ====
 
@@ -170,9 +170,9 @@ Jetzt haben Sie noch ein paar Aufgaben vor sich, um den Übergang abzuschließen
 * Alle Projekte, die von diesem abhängen, müssen ihren Code und/oder ihre Konfiguration aktualisieren.
 * Aktualisieren Sie alle Test-Runner Konfigurationsdateien.
 * Passen Sie Build- und Release-Skripte an.
-* Leiten Sie die Einstellungen auf Ihrem Repo-Host für Dinge wie den Standardbranch des Repos, Zusammenführungsregeln und andere Dinge um, die mit den Branchnamen übereinstimmen.
+* Richten sie Umleitungen auf Ihrem Repo-Host für Dinge wie den Standardbranch des Repos, Merge-Regeln und andere Dinge ein, die mit Branchnamen übereinstimmen.
 * Aktualisieren Sie die Verweise auf den alten Branch in der Dokumentation.
-* Schließen oder Mergen sie alle Pull-Anforderungen, die auf den alten Branch abzielen.
+* Schließen oder Mergen sie alle Pull-Requests, die auf den alten Branch zeigen.
 
 Nachdem Sie alle diese Aufgaben erledigt haben und sicher sind, dass der `main` Branch genau wie der `master` Branch ausgeführt wird, können Sie den `master` Branch löschen:
 

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

@@ -1,7 +1,7 @@
 [[_git_branches_overview]]
 === Branches auf einen Blick
 
-Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Schritt zurücktreten und untersuchen, wie Git seine Daten speichert.
+Um richtig zu verstehen, wie Git das Verzweigen (engl. Branching) realisiert, müssen wir einen Schritt zurück gehen und untersuchen, wie Git seine Daten speichert.
 
 Wie Sie vielleicht aus Kapitel 1 <<ch01-getting-started#what_is_git_section>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von _Snapshots_.
 
@@ -99,7 +99,7 @@ Lassen Sie uns zu dem neuen `testing` Branch wechseln.
 $ git checkout testing
 ----
 
-Dadurch wird `HEAD` verschoben, um auf den Zweig `testing` zu zeigen.
+Dadurch wird `HEAD` verschoben, um auf den Branch `testing` zu zeigen.
 
 .HEAD zeigt auf den aktuellen Branch
 image::images/head-to-testing.png[HEAD zeigt auf den aktuellen Branch]
@@ -130,9 +130,9 @@ $ git checkout master
 Wenn Sie jetzt `git log` aufrufen würden, könnten Sie sich fragen, wohin der gerade erstellte „testing“ Branch verschwunden ist, da er nicht in der Anzeige auftauchen würde.
 
 Der Branch ist nicht spurlos verschwunden. Git weiß nur nicht, dass Sie sich für diesen Branch interessieren, und es versucht, Ihnen das zu zeigen, woran Sie seiner Meinung nach interessiert sind.
-Anders gesagt, standardmäßig zeigt `git log` nur den Commit-Verlauf innerhalb des Branches an, den Sie ausgecheckt haben.
+Anders gesagt, standardmäßig zeigt `git log` nur den Commit-Verlauf des Branches an, den Sie ausgecheckt haben.
 
-Um die Commit-Historie für den gewünschten Zweig anzuzeigen, müssen Sie ihn explizit angeben: `git log testing`.
+Um die Commit-Historie für den gewünschten Branch anzuzeigen, müssen Sie ihn explizit angeben: `git log testing`.
 Um alle Branches zu sehen, fügen Sie `--all` zu Ihrem Kommando `git log` hinzu.
 ====
 
@@ -169,7 +169,7 @@ Und das alles mit den einfachen Befehlen `branch`, `checkout` und `commit`.
 .Verzweigter Verlauf
 image::images/advance-master.png[Verzweigter Verlauf]
 
-Sie können sich dies auch mühelos ansehen, wenn Sie die Anweisung `git log` ausführen.
+Sie können sich dies ansehen, wenn Sie die Anweisung `git log` ausführen.
 Wenn Sie die Anweisung `git log --oneline --decorate --graph --all` ausführen, wird Ihnen der Verlauf Ihrer Commits so angezeigt, dass erkennbar ist, wo Ihre Branch-Zeiger sich befinden und wie Ihr Verlauf sich verzweigt hat.
 
 [source,console]