Osantiago/ch07 vom sie zum du (#386)

* ch07-vom-sie-zum-du

* some more changes

* advanced merging file

* 07 rerere.asc file

* 07-rerere kleiner Fixes

* ch07 debugging.asc

* ch07 submodules - 1

* ch07 - weiter Kapitel und generelle Ersetzungen

Author: pastatopf

C-git-commands.asc

@@ -335,7 +335,7 @@ Wir richten in <<ch10-git-internals#_refspec>> eigene Referenzspezifikationen ei
 
 Der `git pull` Befehl ist im Grunde eine Kombination aus den `git fetch` und `git merge` Befehlen, wobei Git von dem angegebenen Remote holt und dann sofort versucht, es in den Branch, auf dem Sie gerade sind, zu integrieren.
 
-Wir führen ihn in <<ch02-git-basics-chapter#_fetching_and_pulling>> ein und zeigen in <<ch02-git-basics-chapter#_inspecting_remote>> auf, was alles gemergt wird, wenn Sie ihn benutzen.
+Wir führen ihn in <<ch02-git-basics-chapter#_fetching_and_pulling>> ein und zeigen in <<ch02-git-basics-chapter#_inspecting_remote>> auf, was alles gemerged wird, wenn Sie ihn benutzen.
 
 Wir erfahren in <<ch03-git-branching#_rebase_rebase>> auch, wie Sie damit bei Schwierigkeiten während des Rebasings umgehen können.
 

TRANSLATING.md

@@ -76,7 +76,7 @@ Auf https://git-scm.com sind die Übersetzungen in drei Kategorien eingeteilt. S
 
 GitHub Actions ist ein [Continuous Integration](https://de.wikipedia.org/wiki/Kontinuierliche_Integration)-Dienst, der in GitHub integriert ist. GitHub Actions wird verwendet, um sicherzustellen, dass ein Pull-Request den Build oder die Kompilierung nicht unterbricht. GitHub Actions kann auch kompilierte Versionen des Buchs bereitstellen.
 
-Die Konfiguration für GitHub-Aktionen ist im Verzeichnis `.github/workflows` enthalten, und wenn Sie den `main`-Zweig des Root-Repositorys einbinden, erhalten Sie sie kostenlos.
+Die Konfiguration für GitHub-Aktionen ist im Verzeichnis `.github/workflows` enthalten, und wenn Sie den `main`-Branch des Root-Repositorys einbinden, erhalten Sie sie kostenlos.
 Wenn Sie jedoch Ihr Übersetzungsrepo erstellt haben, indem Sie das Root-Repository _geforked_ haben, müssen Sie einen zusätzlichen Schritt ausführen (wenn Sie keinen Fork gemacht haben, können Sie diesen Teil überspringen).
 GitHub geht davon aus, dass Forks verwendet werden, um zu dem Repository beizutragen, aus dem sie geforked wurden. Sie müssen also die Registerkarte „Aktionen“ in Ihrem geforktem Repository aufrufen und auf die Schaltfläche „Ich verstehe meine Workflows“ klicken, um die Aktionen zuzulassen.
 

TRANSLATION_NOTES_DE.asc

@@ -12,9 +12,9 @@ Wenn Sie an der deutschen Übersetzung mitarbeiten wollen, können Sie dazu ein
 
 * Bitte erstellen Sie erst dann einen Pull-Request, wenn Sie ein Arbeitspaket abgeschlossen haben. Bitte beschreiben Sie im Pull-Request, was Ihr zu mergender Branch enthält (neue Übersetzungen, Korrekturen usw.).
 
-* Wir werden Ihren Beitrag prüfen und ein weiterer Helfer wird Ihr Ergebnis Korrektur lesen (Review). Das kann dazu führen, dass Sie Ihre Arbeit noch einmal überarbeiten müssen. Bitte sehen Sie das Review als positive Hilfestellung, damit das Ergebnis insgesamt besser wird, und nehmen Sie die Kritik nicht negativ auf. Wir wollen damit sicherstellen, dass die deutsche Übersetzung einheitlicher wird und in einer guten Qualität zur Verfügung steht. Wenn alles passt, nehmen wir das Ergebnis in den Hauptzweig auf und veröffentlichen es für die bekannten Seiten.
+* Wir werden Ihren Beitrag prüfen und ein weiterer Helfer wird Ihr Ergebnis Korrektur lesen (Review). Das kann dazu führen, dass Sie Ihre Arbeit noch einmal überarbeiten müssen. Bitte sehen Sie das Review als positive Hilfestellung, damit das Ergebnis insgesamt besser wird, und nehmen Sie die Kritik nicht negativ auf. Wir wollen damit sicherstellen, dass die deutsche Übersetzung einheitlicher wird und in einer guten Qualität zur Verfügung steht. Wenn alles passt, nehmen wir das Ergebnis in den Haupt-Branch auf und veröffentlichen es für die bekannten Seiten.
 
-* Wenn Ihr Ergebnis sehr weit vom Master-Zweig abweicht, kann es passieren, dass wir Sie um einen link:https://git-scm.com/book/de/v1/Git-Branching-Rebasing[Rebase] bitten.
+* Wenn Ihr Ergebnis sehr weit vom Master-Branch abweicht, kann es passieren, dass wir Sie um einen link:https://git-scm.com/book/de/v1/Git-Branching-Rebasing[Rebase] bitten.
 
 * Da bei der deutschen Übersetzung ausschließlich deutschsprachige Mitarbeiter mitwirken, sollte die Commit-Beschreibung auf Deutsch erfolgen. Bitte wenden Sie die üblichen Git Commit-Beschreibungskonventionen an.
 
@@ -72,7 +72,7 @@ Vorgänger; Singular: der Vorgänger; Plural: die Vorgänger
 |to apply|
 anwenden
 |Branch|
-Branch; Singular: der Branch; Plural: die Branches; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden.
+Branch; Singular: der Branch; Plural: die Branches; Vorzugsweise die englische Version nutzen.
 |Branchname|
 Branchname; Singular: der Branchname; Plural: die Branchnamen
 |to clone|
@@ -106,7 +106,7 @@ Diff; Singular: der Diff; Plural: die Diffs; Vorzugsweise die englische Version
 |Flag|
 Singular: der Flag; Plural: die Flags, siehe https://de.wikipedia.org/wiki/Flag_(Informatik)[Wikipedia].
 |Feature|
-Singular: das Thema; Plural: die Eigenschaften
+Singular: das Thema; Plural: die Eigenschaften; Feature-Branch: Vorzugsweise die englische Version nutzen
 |to fetch|
 fetchen; er/sie fetcht; wir fetchen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'abholen' verwendet werden
 |to fork|
@@ -137,7 +137,7 @@ Projektbetreuer
 |to maintain|
 betreuen
 |to merge|
-mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „zusammenführen oder verschmelzen“ verwendet werden.
+mergen; er/sie merged; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „zusammenführen oder verschmelzen“ verwendet werden.
 |namespace|
 namespace; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Namensraum“ verwendet werden.
 |packfile|

book/01-introduction/sections/history.asc

@@ -12,7 +12,7 @@ Die Ziele des neuen Systems waren unter anderem:
 
 *  Geschwindigkeit
 *  Einfaches Design
-*  Gute Unterstützung von nicht-linearer Entwicklung (tausende parallele Entwicklungszweige)
+*  Gute Unterstützung von nicht-linearer Entwicklung (tausende parallele Entwicklungs-Branches)
 *  Vollständig dezentrale Struktur
 *  Fähigkeit, große Projekte, wie den Linux Kernel, effektiv zu verwalten (Geschwindigkeit und Datenumfang)
 

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

@@ -33,7 +33,7 @@ nothing to commit, working tree clean
 Dieser Zustand wird auch als sauberes Arbeitsverzeichnis (engl. clean working directory) bezeichnet.
 Mit anderen Worten, es gibt keine Dateien, die unter Versionsverwaltung stehen und seit dem letzten Commit geändert wurden – andernfalls würden sie hier aufgelistet werden.
 Außerdem teilt dir der Befehl mit, auf welchem Branch du gerade arbeitest und informiert dich darüber, dass dieser sich im Vergleich zum Branch auf dem Server nicht verändert hat.
-Momentan ist dieser Zweig immer `master`, was der Vorgabe entspricht; Du musst dich jetzt nicht darum kümmern.
+Momentan ist dieser Branch immer `master`, was der Vorgabe entspricht; Du musst dich jetzt nicht darum kümmern.
 Wir werden im Kapitel <<ch03-git-branching#ch03-git-branching,Git Branching>> detaillierter auf Branches eingehen.
 
 [NOTE]

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

@@ -179,7 +179,7 @@ $ git remote show origin
 ----
 
 Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branches auf.
-Der Befehl teilt dir mit: Wenn du dich im Master-Zweig befindest und `git pull` ausführst, der `master` Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird.
+Der Befehl teilt dir mit: Wenn du dich im Master-Branch befindest und `git pull` ausführst, 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 du möglicherweise treffen wirst.
@@ -209,8 +209,8 @@ $ git remote show origin
     master                         pushes to master                         (up to date)
 ----
 
-Dieser Befehl zeigt an, zu welchem Zweig automatisch gepusht wird, wenn du `git push` ausführst, während du dich in bestimmten Branches befindest.
-Er zeigt dir auch, welche entfernten Branches auf dem Server vorhanden sind, die du noch nicht hast, welche entfernten Branches du hast, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit deinen Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn du `git pull` ausführst.
+Dieser Befehl zeigt an, zu welchem Branch automatisch gepusht wird, wenn du `git push` ausführst, während du dich in bestimmten Branches befindest.
+Er zeigt dir auch, welche entfernten Branches auf dem Server vorhanden sind, die du noch nicht hast, welche entfernten Branches du hast, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit deinen Remote-Tracking-Branch zusammengeführt (gemerged) werden können, wenn du `git pull` ausführst.
 
 ==== Umbenennen und Entfernen von Remotes
 

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

@@ -106,7 +106,7 @@ Fast-forward
 
 Dir wird bei diesem Zusammenführen der Ausdruck „fast-forward“ auffallen.
 Da der Commit `C4`, auf den der von dir eingebundene Branch `hotfix` zeigt, direkt vor dem Commit `C2` liegt, auf dem du dich befindest, bewegt Git den Pointer einfach nach vorne.
-Um es anders auszudrücken: Wenn du versuchst, einen Commit mit einem Commit zusammenzuführen, der durch Verfolgen der Historie des ersten Commits erreicht werden kann, vereinfacht Git die Dinge, indem er den Zeiger nach vorne bewegt, da es keine verzweigte Arbeiten gibt, die miteinander gemergt werden müssen – das wird als „fast-forward“ bezeichnet.
+Um es anders auszudrücken: Wenn du versuchst, einen Commit mit einem Commit zusammenzuführen, der durch Verfolgen der Historie des ersten Commits erreicht werden kann, vereinfacht Git die Dinge, indem er den Zeiger nach vorne bewegt, da es keine verzweigte Arbeiten gibt, die miteinander gemerged werden müssen – das wird als „fast-forward“ bezeichnet.
 
 Deine Änderung befindet sich nun im Schnappschuss des Commits, auf den der `master` Branch zeigt und du kannst deinen Fix ausliefern und installieren.
 

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

@@ -37,7 +37,7 @@ $ git branch --merged
 * master
 ----
 
-Da du den Branch `iss53` schon früher gemergt hast, siehst du ihn in dieser Liste.
+Da du den Branch `iss53` schon früher gemerged hast, siehst du 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; Du hast deren Änderungen bereits zu einem anderen Branch hinzugefügt, sodass du nichts verlieren würdest.
 
 Um alle Branches zu sehen, welche Änderungen enthalten, die du noch nicht integriert hast, könntest du die Anweisung `git branch --no-merged` ausführen:
@@ -62,7 +62,7 @@ Wenn du den Branch wirklich löschen und diese Bearbeitungen aufgeben willst, ka
 
 [TIP]
 ====
-Wenn du keinen Commit- oder Branch-Namen als Argument angibst, zeigen dir die oben beschriebenen Optionen `--merged` und `--no-merged` was jeweils in deinem _current_-Branch gemergt oder nicht gemergt wurde.
+Wenn du keinen Commit- oder Branch-Namen als Argument angibst, zeigen dir die oben beschriebenen Optionen `--merged` und `--no-merged` was jeweils in deinem _current_-Branch gemerged oder nicht gemerged wurde.
 
 Du kannst immer ein zusätzliches Argument angeben, um nach dem Merge-Status in Bezug auf einen anderen Branch zu fragen, ohne zu diesen anderen Branch wechseln zu müssen. So wie im Beispiel unten: „Was ist nicht in den Branch `master` integriert?“
 [source,console]
@@ -79,7 +79,7 @@ $ git branch --no-merged master
 [CAUTION]
 ====
 Benenne keine Branches um, die noch von anderen Mitstreitern verwendet werden.
-Benenne einen Branch wie master / main / mainline nicht um, ohne den Abschnitt „Ändern des Namens des Hauptzweigs“ gelesen zu haben.
+Benenne einen Branch wie master / main / mainline nicht um, ohne den Abschnitt „Ändern des Namens des Haupt-Branch“ gelesen zu haben.
 ====
 
 Angenommen, du hast einen Branch mit dem Namen `bad-branch-name` und möchtest ihn in `corrected-branch-name` ändern, während die gesamte Historie beibehalten wird.

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

@@ -161,7 +161,7 @@ $ git commit -a -m 'made other changes'
 ----
 
 Jetzt hat sich dein Projektverlauf verzweigt (siehe <<divergent_history,Verzweigter Verlauf>>).
-Du hast einen Branch erstellt und bist zu ihm gewechselt, hast einige Arbeiten daran durchgeführt und bist dann wieder zu deinem Hauptzweig zurückgekehrt, um andere Arbeiten durchzuführen.
+Du hast einen Branch erstellt und bist zu ihm gewechselt, hast einige Arbeiten daran durchgeführt und bist dann wieder zu deinem Haupt-Branch zurückgekehrt, um andere Arbeiten durchzuführen.
 Beide Änderungen sind in separaten Branches isoliert: Du kannst zwischen den Branches hin und her wechseln sowie sie zusammenführen, wenn du soweit bist.
 Und das alles mit den einfachen Befehlen `branch`, `checkout` und `commit`.
 

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

@@ -13,7 +13,7 @@ Wenn du dich noch mal ein früheres Beispiel aus <<_basic_merging,Einfaches Merg
 image::images/basic-rebase-1.png[Einfacher verzweigter Verlauf]
 
 Der einfachste Weg, die Branches zu integrieren ist der Befehl `merge`, wie wir bereits besprochen haben.
-Er führt einen Drei-Wege-Merge zwischen den beiden letzten Zweig-Snapshots (`C3` und `C4`) und dem jüngsten gemeinsamen Vorgänger der beiden (`C2`) durch und erstellt einen neuen Snapshot (und Commit).
+Er führt einen Drei-Wege-Merge zwischen den beiden letzten Branch-Snapshots (`C3` und `C4`) und dem jüngsten gemeinsamen Vorgänger der beiden (`C2`) durch und erstellt einen neuen Snapshot (und Commit).
 
 [[rebasing-merging-example]]
 .Zusammenführen (Merging) verzweigter Arbeitsverläufe
@@ -53,7 +53,7 @@ Jetzt ist der Schnappschuss, der auf `C4'` zeigt, exakt derselbe wie derjenige,
 Es gibt keinen Unterschied im Endergebnis der Integration. Das Rebase sorgt jedoch für eine klarere Historie.
 Wenn man das Protokoll eines rebase Branches betrachtet, sieht es wie eine lineare Historie aus: Es scheint, dass alle Arbeiten sequentiell stattgefunden hätten, auch wenn sie ursprünglich parallel stattgefunden haben.
 
-Häufig wirst du das anwenden, damit deine Commits sauber auf einen Remote-Zweig angewendet werden – vielleicht in einem Projekt, zu dem du beitragen möchtest, das du aber nicht pflegst.
+Häufig wirst du das anwenden, damit deine Commits sauber auf einen Remote-Branch angewendet werden – vielleicht in einem Projekt, zu dem du beitragen möchtest, das du aber nicht pflegst.
 Du würdest deine Änderungen in einem lokalen Branch durchführen und diese im Anschluss mittels rebase zu `origin/master` dem Hauptprojekt hinzufügen.
 Auf diese Weise muss der Maintainer keine Integrationsarbeiten durchführen – nur einen „fast-forward“ oder ein einfaches Einbinden deines Patches.