Rewrite rebase vs merge analogy

Closes #351

Author: HonkingGoose

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

@@ -228,8 +228,10 @@ So what if there was a messy series of merge commits?
 That's how it happened, and the repository should preserve that for posterity.
 
 The opposing point of view is that the commit history is the *story of how your project was made.*
-You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing.
-This is the camp that uses tools like `rebase` and `filter-branch` to tell the story in the way that's best for future readers.
+You wouldn't publish the first draft of a book, so why show your messy work?
+Remember, you are likely to need this history yourself, when fixing a bug, or figuring out why you made a particular change.
+People in this camp clean up their commit(s) and commit messages, before the work is merged/rebased into the mainline branch.
+They use tools like `rebase` and `filter-branch`, to tell the story in the way that's best for future readers.
 
 Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple.
 Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different.