Merge pull request #107 from max123kl/English_Commits

including English commits (Nr. 1433 und1435)

Author: max123kl

book/05-distributed-git/sections/distributed-workflows.asc

@@ -37,7 +37,6 @@ Mit dem Verzweigungs-Modell (Branching-Modell) von Git ist es Hunderten von Entw
 ==== Arbeitsablauf mit Integrationsmanager
 
 (((Workflows, Integrations-Manager)))
-
 Da Sie in Git über mehrere Remote-Repositorys verfügen können, ist ein Workflow möglich, bei dem jeder Entwickler Schreibzugriff auf sein eigenes, öffentliches Repository und Lesezugriff auf die Repositorys aller anderen Entwickler hat.
 Dieses Szenario enthält häufig ein zentrales Repository, das das „offizielle“ Projekt darstellt.
 Um zu diesem Projekt beizutragen, erstellen Sie Ihren eigenen öffentlichen Klon des Projekts und laden Ihre Änderungen dort hoch.
@@ -84,6 +83,18 @@ image::images/benevolent-dictator.png[Arbeitsablauf mit wohlwollendem Diktator.]
 Diese Art von Arbeitsablauf ist nicht weit verbreitet, kann jedoch in sehr großen Projekten oder in sehr hierarchischen Umgebungen hilfreich sein.
 Dies ermöglicht dem Projektleiter (dem Diktator), einen Großteil der Arbeit zu delegieren und große Teilbereiche von Quelltext an mehreren Stellen zu sammeln, bevor diese integriert werden.
 
+[[_patterns_for_managing_source_code_branches]]
+==== Methoden zur Verwaltung von Quellcode-Branches
+
+[NOTE]
+====
+Martin Fowler hat den Leitfaden „Patterns for Managing Source Code Branches“ (Methoden zur Verwaltung von Quellcode-Branches) erstellt.
+Dieser Leitfaden deckt alle gängigen Git-Workflows ab und erklärt, wie und wann sie eingesetzt werden sollten.
+Es gibt auch einen Abschnitt, in dem hohe und niedrige Integrationsfrequenzen verglichen werden.
+
+https://martinfowler.com/articles/branching-patterns.html
+====
+
 ==== Zusammenfassung
 
 Dies sind einige häufig verwendete Workflows, die mit einem verteilten System wie Git möglich sind. Allerdings sind auch viele Variationen möglich, um Ihren eigenen Arbeitsabläufen gerecht zu werden.

book/07-git-tools/sections/rewriting-history.asc

@@ -292,10 +292,12 @@ $ git log -4 --pretty=format:"%h %s"
 1c002dd Add cat-file
 9b29157 Add blame
 35cfb2b Update README formatting
-f3cc40e Change my name a bit
+f7f3f6d Change my name a bit
 ----
 
-Zur Erinnerung, das ändert die SHA-1s *aller* Commits in Ihrer Liste, also stellen Sie sicher, dass *kein* Commit in dieser Liste auftaucht, den Sie bereits in ein gemeinsames Repository gepusht haben.
+Dies ändert die SHA-1s der drei jüngsten Commits in Ihrer Liste, stellen Sie also sicher, dass kein geänderter Commit in dieser Liste auftaucht, den Sie bereits in ein gemeinschaftliches Repository verschoben haben.
+Beachten Sie, dass der letzte Commit (`f7f3f6d`) in der Liste nicht geändert wurde.
+Trotzdem wird dieser Commit im Skript angezeigt, da er als „pick“ markiert war und vor jeglichen Rebase-Änderungen angewendet wurde. Git lässt den Commit unverändert.
 
 ==== Die Nuklear-Option: filter-branch