The git pull command will get the latest changes from the source (origin by default) and immediately try to merge them with your code in your current branch. If there's no overlap, it will be a breeze.
git pull --rebase will do the same, except it'll try to apply your changes onto the end of the stream of incoming ones so they look like one simple progression. You would only notice the difference if you looked at the history (git log) from both methods. (See this page for a demo.)
If you're concerned about overlap of your changes with ones from the origin and would like a "preview" before you attempt to merge them, then you could use the command git fetch origin to bring down all the latest changes into a hidden local branch called 'origin/master'--which is different than your 'master' branch. You could then choose to browse around it by git merge origin/master (note that you will see a warning message that this isn't a "real" branch, but it still works), and later merge it with your code (first git checkout master if you weren't already there, then git merge origin/master).
(As adymitruk mentioned, it is easiest to make your changes in a separate branch (git checkout -b my_branch), and then fetch-and-merge or pull. But if you've already been working on the local master branch, the aforementioned commands will get you there.)