don't encourage people to force push ever

progit · schacon · Jun 10, 2014 · Jun 4, 2014 · Jun 4, 2014 · Jun 4, 2014
commit b4ac3fafbb85bfaa821132708bc063ad3039e250
diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc
@@ -987,12 +987,13 @@ 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.
-If that requires a force-push every now and then, so be it.
 
 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.
 
+In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere.
+
 === Summary
 
 We've covered basic branching and merging in Git.