Chapter 9 - Vom Sie zum Du (progit#395)

saxc · May 18, 2024 · 5e3d89e · 5e3d89e
1 parent 8e74a2a
commit 5e3d89e
Show file tree

Hide file tree

Showing 21 changed files with 345 additions and 645 deletions.
diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc
@@ -162,7 +162,7 @@ index.html |    1 +
 Das sieht ein bisschen anders aus, als das Merging mit dem `hotfix` Branch, welches du zuvor gemacht hast.
 Hier hat sich der Entwicklungsverlauf an einem früheren Zustand geteilt.
 Da der Commit auf dem Branch, auf dem du dich gerade befindest, kein unmittelbarer Vorgänger des Branches ist, in den du mergst, 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 Vorgänger der beiden zeigen.
+In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die das Branch-Ende 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]

diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc
@@ -19,7 +19,7 @@ Er führt einen Drei-Wege-Merge zwischen den beiden letzten Branch-Snapshots (`C
 .Zusammenführen (Merging) verzweigter Arbeitsverläufe
 image::images/basic-rebase-2.png[Zusammenführen (Merging) verzweigter Arbeitsverläufe]
 
-Allerdings gibt es noch einen anderen Weg: Du kannst den Patch der Änderungen, den wir in `C4` eingeführt haben, nehmen und an der Spitze von `C3` erneut anwenden.
+Allerdings gibt es noch einen anderen Weg: Du kannst den Patch der Änderungen, den wir in `C4` eingeführt haben, nehmen und am Ende von `C3` erneut anwenden.
 Dieses Vorgehen nennt man in Git _rebasing_.
 Mit dem Befehl `rebase` kannst du alle Änderungen, die in einem Branch vorgenommen wurden, übernehmen und in einem anderen Branch wiedergeben.(((Git Befehle, rebase)))
 
@@ -106,11 +106,11 @@ Du kannst das Rebase des `server` Branches auf den `master` Branch anwenden, ohn
 $ git rebase master server
 ----
 
-Das wiederholt deine Änderungen aus dem `server` Branch an der Spitze des `master` Branches, wie in <<rbdiag_h>> gezeigt wird.
+Das wiederholt deine Änderungen aus dem `server` Branch am Ende des `master` Branches, wie in <<rbdiag_h>> gezeigt wird.
 
 [[rbdiag_h]]
-.Rebase deines `server` Branches an der Spitze deines `master` Branches
-image::images/interesting-rebase-4.png[Rebase deines `server` Branches an der Spitze deines `master` Branches]
+.Rebase deines `server` Branches am Ende deines `master` Branches
+image::images/interesting-rebase-4.png[Rebase deines `server` Branches am Ende deines `master` Branches]
 
 Dann kannst du den Basis-Branch (`master`) vorspulen (engl. fast-forward):
 
@@ -193,13 +193,13 @@ Sobald wir im vorhergehenden Szenario, beispielsweise bei <<_pre_merge_rebase_wo
 * bestimmen, welche Änderungen an unserem Branch einmalig sind (`C2`, `C3`, `C4`, `C6`, `C7`),
 * bestimmen, welche der Commits keine Merge-Commits sind (`C2`, `C3`, `C4`),
 * bestimmen, welche Commits nicht neu in den Zielbranch geschrieben wurden (nur `C2` und `C3`, da `C4` der selbe Patch wie `C4'` ist), und
-* diese Commits auf die Spitze des `teamone/master` Branches anwenden.
+* diese Commits am Ende des `teamone/master` Branches anwenden.
 
 Statt des Ergebnisses, welches wir in <<_merge_rebase_work>> sehen, würden wir etwas erhalten, was eher wie <<_rebase_rebase_work>> aussieht.
 
 [[_rebase_rebase_work]]
-.Rebase an der Spitze von Änderungen eines „force-pushed“-Rebase
-image::images/perils-of-rebasing-5.png[Rebase an der Spitze von Änderungen eines „force-pushed“-Rebase]
+.Rebase am Ende von Änderungen eines „force-pushed“-Rebase
+image::images/perils-of-rebasing-5.png[Rebase am Ende von Änderungen eines „force-pushed“-Rebase]
 
 Das funktioniert nur, wenn es sich bei `C4` und `C4'`, welche dein Teamkollege erstellt hat, um fast genau denselben Patch handelt.
 Andernfalls kann das rebase nicht erkennen, dass es sich um ein Duplikat handelt und fügt einen weiteren, dem Patch `C4` ähnlichen, hinzu (der wahrscheinlich nicht sauber angewendet werden kann, da die Änderungen bereits vollständig oder zumindest teilweise vorhanden sind).

diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc
@@ -30,7 +30,7 @@ Wenn du stattdessen die Anweisung `git clone -o booyah` ausführen, erhältst du
 .Entfernte und lokale Repositorys nach dem Klonen
 image::images/remote-branches-1.png[Entfernte und lokale Repositorys nach dem Klonen]
 
-Wenn du ein wenig an deinem lokalen `master` Branch arbeitest und in der Zwischenzeit jemand anderes etwas zu `git.ourcompany.com` hochlädt und damit dessen `master` Branch aktualisiert, dann bewegen sich Ihre Verläufe unterschiedlich vorwärts.
+Wenn du ein wenig an deinem lokalen `master` Branch arbeitest und in der Zwischenzeit jemand anderes etwas zu `git.ourcompany.com` hochlädt und damit dessen `master` Branch aktualisiert, dann bewegen sich eure Verläufe unterschiedlich vorwärts.
 Solange du keinen Kontakt mit deinem `origin` Server aufnimmst, bewegt sich dein `origin/master` Zeiger nicht.
 
 .Lokale und entfernte Änderungen können Auseinanderlaufen
@@ -98,7 +98,7 @@ Am einfachsten ist es, die Informationen nur für einige Minuten im Speicher zu
 Weitere Informationen zu den verschiedenen verfügbaren „credential cache“ Optionen findest du in Kapitel 7 <<ch07-git-tools#_credential_caching,Caching von Anmeldeinformationen>>.
 ====
 
-Das nächste Mal, wenn einer Ihrer Mitstreiter Daten vom Server abholt, wird er eine Referenz auf die Server-Version des Branches `serverfix` unter dem Remote-Branch `origin/serverfix` erhalten:
+Das nächste Mal, wenn einer deiner Mitstreiter Daten vom Server abholt, wird er eine Referenz auf die Server-Version des Branches `serverfix` unter dem Remote-Branch `origin/serverfix` erhalten:
 
 [source,console]
 ----

diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc
@@ -50,7 +50,7 @@ Als Nächstes, versuchst du, aus jedem Commit einen logisch getrennten Satz von
 Versuche deine Änderungen leicht verständlich zu machen. Arbeiten nicht ein ganzes Wochenende an fünf verschiedenen Features und übermittel all diese Änderungen in einem massiven Commit am Montag.
 Auch wenn du am Wochenende keine Commits durchführst, nutze am Montag die Staging-Area, um deine Änderungen aufzuteilen in wenigstens einen Commit für jeden Teilaspekt mit jeweils einer sinnvollen Nachricht.
 Wenn einige der Änderungen dieselbe Datei modifizieren, benutze die Anweisung `git add --patch`, um Dateien partiell zur Staging-Area hinzuzufügen (detailliert dargestellt im Abschnitt <<ch07-git-tools#_interactive_staging>>).
-Der Schnappschuss vom Projekt an der Spitze des Branches ist der Selbe, ob du einen oder fünf Commits durchgeführt hast, solange nur all die Änderungen irgendwann hinzugefügt werden. Versuche also, die Dinge für deine Entwicklerkollegen zu vereinfachen, die deine Änderungen begutachten müssen.
+Der Schnappschuss vom Projekt am Ende des Branches ist der Selbe, ob du einen oder fünf Commits durchgeführt hast, solange nur all die Änderungen irgendwann hinzugefügt werden. Versuche also, die Dinge für deine Entwicklerkollegen zu vereinfachen, die deine Änderungen begutachten müssen.
 
 Dieser Ansatz macht es außerdem einfacher, einen Satz von Änderungen zu entfernen oder rückgängig zu machen, falls das später nötig sein sollte.
 <<ch07-git-tools#_rewriting_history>> beschreibt eine Reihe nützlicher Git-Tricks zum Umschreiben des Verlaufs oder um interaktiv Dateien zur Staging-Area hinzuzufügen. Verwende diese Werkzeuge, um einen sauberen und leicht verständlichen Verlauf aufzubauen, bevor du deine Arbeit jemand anderem schickst.

diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc
@@ -66,7 +66,7 @@ Nun sehen die Betrachter überall dort, wo du auf der Website agierst, dein Avat
 
 Wenn du beim beliebten Gravatar-Dienst (der oft für Wordpress-Konten verwendet wird) einen Avatar hochgeladen hast, wird dieser standardmäßig verwendet und du musst diesen Schritt nicht mehr ausführen.
 
-==== Ihre Email-Adressen
+==== Deine Email-Adressen
 
 GitHub bildet deine Git Commits auf deinen Account ab, wobei die Zuordnung per E-Mail erfolgt.
 Wenn du mehrere E-Mail-Adressen in deine Commits verwendest und möchtest, dass GitHub diese korrekt verknüpft, musst du alle von dir verwendeten E-Mail-Adressen in den E-Mail-Bereich des Admin-Bereichs aufnehmen.

diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -572,7 +572,7 @@ $ git revert -m 1 HEAD
 ----
 
 Das `-m 1` Flag gibt an, welches Elternteil auf der „Hauptlinie“ ist und beibehalten werden sollte.
-Wenn du einen Merge zu `HEAD` (`git merge topic`) startest, hat der neue Commit zwei Elternteile: der erste ist `HEAD` (`C6`), und der zweite ist die Spitze des Branchs, der gemerged wird (`C4`).
+Wenn du einen Merge zu `HEAD` (`git merge topic`) startest, hat der neue Commit zwei Elternteile: der erste ist `HEAD` (`C6`), und der zweite ist das Ende des Branchs, der gemerged wird (`C4`).
 Hier wollen wir alle Änderungen rückgängig machen, die durch das Mergen im übergeordneten Teil #2 (`C4`) vorgenommen wurden, wobei der gesamte Inhalt des übergeordneten Teils #1 (`C6`) beibehalten wird.
 
 Der Verlauf mit dem Revert-Commit sieht so aus:

diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc
@@ -89,7 +89,7 @@ Git geht dazu über, SHA256 als Standard-Hashing-Algorithmus zu verwenden, der g
 [[_branch_references]]
 ==== Branch Referenzen
 
-Eine unkomplizierte Methode, auf einen bestimmten Commit zu verweisen, ist, wenn es sich um den Commit an der Spitze eines Branches handelt. In diesem Fall kannst du einfach den Branch-Namen in jedem Git-Befehl verwenden, der eine Referenz auf einen Commit erwartet.
+Eine unkomplizierte Methode, auf einen bestimmten Commit zu verweisen, ist, wenn es sich um den Commit am Ende eines Branches handelt. In diesem Fall kannst du einfach den Branch-Namen in jedem Git-Befehl verwenden, der eine Referenz auf einen Commit erwartet.
 Wenn du beispielsweise das letzte Commit-Objekt in einem Branch untersuchen möchtest, sind die folgenden Befehle gleichwertig, vorausgesetzt, der Branch `topic1` zeigt auf den Commit `ca82a6d....`:
 
 [source,console]
@@ -128,7 +128,7 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 ----
 
-Jedes Mal, wenn die Spitze deines Branch aus irgendeinem Grund aktualisiert wird, speichert Git diese Informationen für dich in dieser temporären Historie.
+Jedes Mal, wenn das Ende deines Branch aus irgendeinem Grund aktualisiert wird, speichert Git diese Informationen für dich in dieser temporären Historie.
 Du kannst deine Reflog-Daten auch verwenden, um auf ältere Commits zu verweisen.
 Wenn du beispielsweise den fünft-letzten Wert des HEADs deines Repositorys sehen möchtest, kannst du den Verweis `@{5}` benutzen, damit du diese Reflog-Ausgabe erhältst:
 
@@ -145,7 +145,7 @@ Um zum Beispiel zu sehen, wo dein `master` Branch gestern war, kannst du folgend
 $ git show master@{yesterday}
 ----
 
-Das würde dir zeigen, wo die Spitze deines `master` Branchs gestern war.
+Das würde dir zeigen, wo das Ende deines `master` Branchs gestern war.
 Diese Technik funktioniert nur für Daten, die sich noch in deinem Reflog befinden. Daher kannst du sie nicht verwenden, um nach Commits zu suchen, die älter als ein paar Monate sind.
 
 Um die Reflog-Informationen so zu formatieren, wie die Ausgabe von `git log`, kannst du `git log -g` aufrufen:

diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc
@@ -207,7 +207,7 @@ Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b2
 ----
 
 Wenn du das Projekt bereits geklont und `--recurse-submodules` vergessen hast, kannst du die Schritte `git submodule init` und `git submodule update` zur Aktualisierung auch kombinieren, indem du `git submodule update --init` aufrufst.
-Damit auch verschachtelte Submodule initialisiert, gefetcht und ausgecheckt werden, kannst du das narrensichere `git submodule update --init --recursive` verwenden.
+Damit auch verschachtelte Submodule initialisiert, gefetched und ausgecheckt werden, kannst du das narrensichere `git submodule update --init --recursive` verwenden.
 
 ==== Arbeiten an einem Projekt mit Submodulen
 

diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc
@@ -85,7 +85,7 @@ feel free to be detailed.
 
 Diese Commit-Vorlage erinnert den Committer daran, die Betreffzeile kurz zu halten (für die `git log --oneline` Ausgabe)., weitere Details hinzuzufügen und sich auf ein Problem oder eine Bug-Tracker-Ticketnummer zu beziehen, falls vorhanden.
 
-Um Git anzuweisen, das als Standardnachricht zu verwenden, die in Ihrem Editor erscheint, wenn du `git commit` ausführst, setze den Konfigurationswert `commit.template`:
+Um Git anzuweisen, das als Standardnachricht zu verwenden, die in deinem Editor erscheint, wenn du `git commit` ausführst, setze den Konfigurationswert `commit.template`:
 
 [source,console]
 ----

diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc