squashing: recommend --keep-base when squashing without a conflict (#…

…2157)

src/git.md

@@ -358,13 +358,24 @@ To avoid merges as per the [No-Merge Policy](#no-merge-policy), you may want to
 to ensure that Git doesn't create merge commits when `git pull`ing, without
 needing to pass `--ff-only` or `--rebase` every time.
 
-You can also `git push --force-with-lease` from master to keep your fork's master in sync with
-upstream.
+You can also `git push --force-with-lease` from master to double-check that your
+feature branches are in sync with their state on the Github side.
 
 ## Advanced Rebasing
 
 ### Squash your commits
 
+"Squashing" commits into each other causes them to be merged into a single
+commit. Both the upside and downside of this is that it simplifies the history.
+On the one hand, you lose track of the steps in which changes were made, but
+the history becomes easier to work with.
+
+If there are no conflicts and you are just squashing to clean up the history,
+use `git rebase --interactive --keep-base master`. This keeps the fork point
+of your PR the same, making it easier to review the diff of what happened
+across your rebases.
+
+Squashing can also be useful as part of conflict resolution.
 If your branch contains multiple consecutive rewrites of the same code, or if
 the rebase conflicts are extremely severe, you can use
 `git rebase --interactive master` to gain more control over the process. This
@@ -375,17 +386,12 @@ Alternatively, you can sacrifice the commit history like this:
 
 ```
 # squash all the changes into one commit so you only have to worry about conflicts once
-git rebase -i $(git merge-base master HEAD)  # and squash all changes along the way
+git rebase -i --keep-base master  # and squash all changes along the way
 git rebase master
 # fix all merge conflicts
 git rebase --continue
 ```
 
-"Squashing" commits into each other causes them to be merged into a single
-commit. Both the upside and downside of this is that it simplifies the history.
-On the one hand, you lose track of the steps in which changes were made, but
-the history becomes easier to work with.
-
 You also may want to squash just the last few commits together, possibly
 because they only represent "fixups" and not real changes. For example,
 `git rebase --interactive HEAD~2` will allow you to edit the two commits only.