TFS get latest version will also force you to do merges if their are conflicts with your changed files, so it's really no different than git pull.
It's generally easier to do a lot of small merges than one big merge at commit time, which is why git's workflow is the way it is.
It is possible (if not a good idea) to do what you ask in git; basically you are trying to defer all merges on files you've changed until you're ready to commit to origin. For git to track this properly, you will need to have a local branch separate from the branch you pull into.
git checkout -b mywork # Create local branch
# ... hack away ...
# When you want to get changes from origin. Note
# that you can script this part to do it as one step.
git commit # Commit my changes to local branch
git checkout master # Go back to branch tracking origin
git pull # Retrieve changes from origin
git checkout mywork
# Here's the tricky part; merge from master, taking your
# code wherever there's a conflict, and *not* recording as
# a merge; if recorded as a merge, you'll overwrite changes
# in master when you merge back
git merge --squash --strategy-option=ours master
# ... hack away ...
When you are ready to push, you merge mywork into master and push from there.
Again, note that you are trading many smaller merges when you pull changes for one big merge when you merge mywork into master, and that's usually not what's best.