pull_request_1481 (#164)

* Changes from July 3rd on original repo

* Changes from July 4th on original repo

* Pull Request 1450

* Pull Request 1470

* pull request 1469

* pull request 1468

* pull request 1477

* pull request 1477

* pull request 1485

* pull request 1481

Author: pastatopf

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

@@ -227,9 +227,10 @@ 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 die Commit-Historie die *Story ist, in der beschrieben wird, wie das Projekt realisiert wurde.*
-Sie würden die erste Fassung eines Buches nicht veröffentlichen, und das Handbuch für die Wartung Ihrer Software verdient eine sorgfältige Bearbeitung.
-Das ist das Lager, das Tools wie `rebase` und `filter-branch` verwendet, um die Story so zu erzählen, wie es für zukünftige Nutzer am sinnvollsten ist.
+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 vonA 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.
+Sie verwenden Tools wie `Rebase` und `Filter-Branch`, um die Geschichte so zu erzählen, wie es für zukünftige Leser am besten ist.
 
 Nun zur Frage, ob Mergen oder Rebasen besser ist. Wie so oft, ist diese Frage nicht so leicht zu beantworten.
 Git ist ein mächtiges Werkzeug und ermöglicht es Ihnen, viele Dinge mit ihrem Verlauf anzustellen, aber jedes Team und jedes Projekt ist anders.