Some of the more-finicky details depend on your Git version, which is what I'm noting in the answer to which you linked. If you want to know the precise difference between various different Git commands, you need to specify the exact commands—including exact spellings of everything—and exact Git versions.
If you want the more general "what does this mostly do", git pull with no options and arguments mostly runs git fetch and then git merge, with the fetch part using the current branch's remote, and the merge part using the current branch's upstream. So whether you do it as one command—git pull, with no arguments at all, or as two separate commands, git fetch and git merge also with no arguments at all—it will do the same thing. Once you start adding various options and arguments, then we have to start getting picky about which Git version you have, and so on.
(You can of course configure git pull to run git rebase as its second command, in which case, substitute git rebase everywhere above. The caveats about small differences that are version-dependent remain. In some ways, they're worse: for instance, fork-point style rebase was initially introduced by git pull only, and then added to git rebase later, in commit ad8261d2122.)
I personally like to run git fetch first, then inspect its output and often run git log second, before running git merge or git rebase third. If you use git pull, inserting the second command is literally impossible.
I also find that for someone new to Git, teaching git fetch separately, then git merge and git rebase, and only then noting that git pull combines these two steps, results in much more ability to use Git effectively. It also provides the reason for the odd syntax that works only with git pull, i.e., why this is origin master and not origin/master.
