Merge pull request #82 from lkwg82/patch-1

fixes typo

Author: max123kl

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

@@ -55,7 +55,7 @@ Wenn man das Protokoll eines rebasierten Branchs betrachtet, sieht es aus wie ei
 
 Häufig werden Sie das anwenden, damit Ihre Commits sauber auf einen Remote-Zweig angewendet werden – vielleicht in einem Projekt, zu dem Sie beitragen möchten, das Sie aber nicht pflegen.
 In diesem Fall würden Sie Ihre Arbeiten in einem Branch erledigen und im Anschluss Ihre Änderungen mittels Rebase zu `origin/master` hinzufügen, wenn Sie soweit sind, Ihre Patches dem Hauptprojekt zu übermitteln.
-Auf diese Weise muss der Maintainer keine Integrationsarbeiten durchführen – nur einen „fast-forward“ oder eine saubere Anwedung Ihres Patches.
+Auf diese Weise muss der Maintainer keine Integrationsarbeiten durchführen – nur einen „fast-forward“ oder eine saubere Anwendung Ihres Patches.
 
 Beachten Sie, dass der Snapshot, auf welchen der letzte Commit zeigt, ob es nun der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, derselbe Schnappschuss ist, nur der Verlauf ist ein anderer.
 Rebasing wiederholt die Änderungsschritte von einer Entwicklungslinie auf einer anderen in der Reihenfolge, in der sie entstanden sind, wohingegen beim Mergen die beiden Endpunkte der Branches genommen und miteinander verschmolzen werden.