Incorporated suggestions into git page and edit for more brevity.

The Advanced Rebasing section has been mostly rewritten to include
both a major suggestion from jyn and a general rewrite.

Author: JakobDegen

src/git.md

@@ -60,7 +60,7 @@ and PRs:
  unintentionally commit changes that should not be committed, such as submodule
  updates. You can use `git status` to check if there are any files you forgot
  to stage.
- 6. Push your changes to your fork: `git push -u origin issue-12345-fix`.
+ 6. Push your changes to your fork: `git push --set-upstream origin issue-12345-fix`.
  7. [Open a PR][ghpullrequest] from your fork to rust-lang/rust's master branch.
 
 [ghpullrequest]: https://guides.github.com/activities/forking/#making-a-pull-request
@@ -119,18 +119,18 @@ master, while the other side has your version of the code. You'll need to
 decide how to deal with the conflict. You may want to keep your changes,
 keep the changes on master, or combine the two.
 
-Generally, resovling the conflict consists of two steps: First, fix the
+Generally, resolving the conflict consists of two steps: First, fix the
 particular conflict. Edit the file to make the changes you want and remove the
 `<<<<<<<`, `=======` and `>>>>>>>` lines in the process. Second, check the
-surrounding code. If there was a conflict, its because someone else changed the
-same code you did. That means its likely there are some logical errors lying
-around too!
+surrounding code. If there was a conflict, its likely there are some logical
+errors lying around too! It's a good idea to run `x.py check` here to make sure
+there are no glaring errors.
 
 Once you're all done fixing the conflicts, you need to stage the files that had
 conflicts in them via `git add`. Afterwards, run `git rebase --continue` to let
 git know that you've resolved the conflicts and it should finish the rebase.
 Once the rebase has succeeded, you'll want to update the associated branch on
-your fork with `git push -f`.
+your fork with `git push --force`.
 
 Note that `git push` will not work properly and say something like this:
 
@@ -145,30 +145,34 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 
 The advice this gives is incorrect! Because of the "no-merge" policy, running
 `git pull` will create a merge commit, defeating the point of your rebase. Use
-`git push -f` instead.
+`git push --force` instead.
 
 ## Advanced Rebasing
 
-Sometimes, you may want to perform a more complicated rebase. There are two
-common scenarios that might call for this.
-
 If your branch contains multiple consecutive rewrites of the same code, or if
-the rebase conflicts are extremely severe, it is possible that just trying to
-reapply the changes you made on top of the updated code will be too much of a
-headache. In this case, you can use the interactive rebase feature via
-`git rebase -i master` to gain more control over the process. This allows you
-to choose to skip commits because they represent changes you no longer need,
-edit the commits that you do not skip, or change the order in which they are
-applied.
-
-The other common scenario is if you are asked to or want to "squash" multiple
-commits into each other. If you PR needs only a minor revision, a single commit
-at the end with message "fixup small issue" is usually unhelpful, and it is
-easier for everyone if you combine that commit with another that has a more
-meaningful commit message. Run `git rebase -i HEAD~2` to edit the last two
-commits so you can merge them together. By selecting the `-i` option, you give
-yourself the opportunity to edit the rebase, similarly to above. This way you
-can request to have the most recent commit squashed into its parent.
+the rebase conflicts are extremely severe, you can use
+`git rebase --interactive master` to gain more control over the process. This
+allows you to choose to skip commits, edit the commits that you do not skip,
+change the order in which they are applied, or "squash" them into each other.
+
+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)  # 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.
+`git rebase --interactive HEAD~2` will allow you to edit the two commits only.
 
 ## No-Merge Policy