You have tried three forms of git diff: no options, --cached, and specifying a single revision (in this case, HEAD). The second answer in the question you've linked to shows a nice graphic summary of what these three forms of git diff do. None of these are what you want.
There are, however, more forms!
You can ask git diff to compare two specific commits (revisions), e.g.:
git diff HEAD@{upstream} HEAD
or:
git diff origin/develop develop
Based on your quoted git status output, these will do the same thing, as HEAD is currently the same as develop (you're "on branch develop" in the git status output), and HEAD@{upstream} will resolve to origin/develop ("ahead of 'origin/develop' by 6 commits"). (Note that in some shells/command-line-interpreters, you may have to quote one or both of the curly braces.)
You can also use:
git diff HEAD@{upstream}..HEAD
This notation, with the literal two-dots .., usually means something else: see the gitrevisions documentation for details. When using git diff, however, the front end command just makes this resolve to the two specified commits and then uses those two.
You'll get quite a bit more—and more typically what you might want, I think—with:
git log -p HEAD@{upstream}..HEAD
as this will show each commit separately, along with the changes made by those commits. Git finds these changes by comparing each commit with its parent commit. (This is also how git figures out which commits are those six. This is described, though in rather graph-theoretical form, in the "SPECIFYING RANGES" section.) In essence, git log -p looks at each commit to be shown, and then does a git diff between that commit's parent, and that commit.
For merge commits, the output of git log -p (and the output of git show, which is like git log -p but only shows the specific commit, or other object, you ask it to show, rather than walking the commit history like git log) is modified: git shows a "combined diff" by default, which tries to highlight what happened in the merge process, rather than what happened in the two branches. You don't need to know much about this now, just remember that when logging or showing a merge, git hides unwanted complexity (which is great until you want it; then search StackOverflow :-) ).
If you leave out the -p, git log will just show the commit messages. See the git log documentation for (many) more options.
As codeWizard noted above, all of these commands use git's idea of "where the remote is" based on the last time git called up the remote and picked up the newest information. This information can be out of date, possibly even by several seconds, or even minutes or (gasp) hours. :-) To get your local git up-to-date with the remote, you must run git fetch (the extra flags, --all and --prune, are not always needed although they may be a good idea depending on who you're sharing with and how). Run git fetch as often, or as rarely, as you like; remember that you could be seconds, or months, out of date, and git won't care either way: how often you want to update is for you to decide.
