Update "cleaning up commits" document with an easier method for rebasing

documentation/cleaning-up-commits.md

@@ -17,16 +17,28 @@ It can be difficult to follow the changes in a pull request when the number of c
 
 ### Rebasing
 
-Sometimes a pull request can be based on a much earlier commit in the branch that you are trying to merge into it, causing a large amount of commits and file changes to litter the pull request. In this case, it would be better to **rebase** (move branches around by changing the commit that they are based on). After rebasing, you will want to close the pull request and open a new one, which will now have fewer commits.
+Sometimes a pull request can be based on a much earlier commit in the branch that you are trying to merge into it, causing a large amount of commits and file changes to litter the pull request. In this case, it would be better to **rebase** (move branches around by changing the commit that they are based on).
 
-For example, if you're working from the branch **feature** and are trying to rebase with **master**, you may run one of the following commands:
-> `git rebase master`
-> `git rebase master feature`
+For example, if you're working from the branch **feature** and are trying to rebase with **dev**, you'll first want to pull the latest changes from **dev**:
 
-You can also rebase with the following command:
-> `git pull --rebase`
+```
+git pull upstream dev
+```
 
-A normal `git pull` is equivalent to `git fetch` followed by `git merge FETCH_HEAD`, but when you run `git pull --rebase`, it runs `git rebase` instead of `git merge`.
+Next, you'll want to "uncommit" all of the changes in **feature** that differ from **dev**:
+
+```
+git reset --soft upstream/dev
+```
+
+Finally, make a small number of commits with the changes you have made and push them to your fork:
+
+```
+< commit changes >
+git push origin feature -f
+```
+
+**Note**: the `-f` must be included when pushing to your fork for the rebase to be successful 
 
 For more information on rebasing, click [here](https://git-scm.com/docs/git-rebase).
 
@@ -35,7 +47,10 @@ For more information on rebasing, click [here](https://git-scm.com/docs/git-reba
 When your pull request has a group of commits that can be condensed into one, logical commit, use **squashing**. This will clean up the number of commits your pull request has while also grouping together common commits. 
 
 For example, if you wanted to squash the last three commits into one, you may run the following command:
-> `git rebase -i HEAD~3`
+
+```
+git rebase -i HEAD~3
+```
 
 This will bring up an editor showing your last three commits. Pick a commit to keep (as the message), and squash the other two into it.
 
@@ -46,13 +61,19 @@ For more information on squashing, click [here](https://git-scm.com/book/en/v2/G
 If you want to merge specific commits from another branch into the current one you are working from, use **cherry-picking**. 
 
 For example, if you're working on the **master** branch and want to pull commit X (the commit-hash) from the **feature** branch, you may run the following commands:
-> `git checkout master`
-> `git cherry-pick X -n`
+
+```
+git checkout master
+git cherry-pick X -n
+```
 
 The `-n`, or `--no-commit`, is recommended for cherry-picking because it won't automatically create a commit for the cherry-picked change; this will allow you to view the changes first and make sure that you want to add all everything from the cherry-picked commit.
 
 Now, if you want to cherry-pick a range of commits, say X through Y, from the **feature** branch, you may run the following commands:
-> `git checkout -b temp-branch X`
-> `git rebase --onto master Y^`
+
+```
+git checkout -b temp-branch X
+git rebase --onto master Y^
+```
 
 For more information on cherry-picking, click [here](https://git-scm.com/docs/git-cherry-pick).