Git does not check with the remote unless you tell it to. So "origin/master" points to what master on origin pointed to the last time git contacted the origin remote.
To have git contact the remote again, you can do "git fetch origin" (or just "git fetch"). Then git will tell you your copy is out of date compared to origin/master, if there's been commits on origin since.
If you commit things, then your copy will be ahead of origin/master, so origin/master is what is out of date and you need to git push:
~/dotfiles % git status ✓✗ master:c024cb4 - dotfiles
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
It's up to date with origin/master, which is the local copy of the remote master. 'git fetch' updates those local copies. 'git pull' does a fetch and then merges origin/master into master.
It makes sense when you consider that there are other ways that origin/master could be updated. You could apply commits that someone emailed you (a common workflow in the Linux kernel that git was designed to support), or someone could push commits directly to you over SSH or the filesystem.
To have git contact the remote again, you can do "git fetch origin" (or just "git fetch"). Then git will tell you your copy is out of date compared to origin/master, if there's been commits on origin since.
If you commit things, then your copy will be ahead of origin/master, so origin/master is what is out of date and you need to git push: