Rewrite into something nicer

Co-authored-by: Ben Straub <[email protected]>

Author: HonkingGoose

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

@@ -229,12 +229,12 @@ 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, 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.
+When you're working on a project, you may need a record of all your missteps and dead-end paths, but when it's time to show your work to the world, you may want to tell a more coherent story of how to get from A to B.
+People in this camp use tools like rebase and filter-branch to rewrite their commits before they're merged 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.
 Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation.
 
-You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you've pushed somewhere.
+You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you've pushed somewhere.