Merge branch 'master' into bugfix/issue-696

Author: ben

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

@@ -228,11 +228,13 @@ 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?
+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.

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

@@ -787,6 +787,11 @@ Result: OK
 
 ==== Summary
 
-This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process.
+In this section, we covered multiple workflows, and talked about the differences between working as part of a small team on closed-source projects vs contributing to a big public project.
+You know to check for white-space errors before committing, and can write a great commit message.
+You learned how to format patches, and e-mail them to a developer mailing list.
+Dealing with merges was also covered in the context of the different workflows.
+You are now well prepared to collaborate on any project.
+
 Next, you'll see how to work the other side of the coin: maintaining a Git project.
 You'll learn how to be a benevolent dictator or integration manager.