Logically, this should be a comment on all three (at the time I wrote this) of the answers that recommend the sequence:
git stash
git pull
git stash pop # or "git stash apply" -- "pop" means "apply, then drop"
all of which are fine answers. But I need room to format things and write a lot. :-)
I don't want to commit these changes
Don't be afraid of committing! You can also commit, then un-commit. In fact, using git stash makes commits: they're just commits that are not on any branch. This can help somewhat with the second thing below. But the key here is to remember that your local branches are yours, to do with as you will.
Using git fetch—which is what git pull does first, before it does a second thing—has no effect on your branches, only on the so-called remote-tracking branches. These remote-tracking branches are your Git's way of remembering what it saw on that other Git at origin. That is, your origin/master, for instance, remembers what they have now. As they make changes in their Git, your origin/master gradually falls behind, but at any time, you can run git fetch and get "what they have now" and your origin/master is once again up to date. This has no effect on your own master.
After the fetch, you need to use some second thing—a second Git command—to incorporate "their" work into one or more of your branches. This second thing can be git merge or git rebase. If you run git pull you have implicitly chosen one of those two commands. I always argue that it is better to choose one explicitly, so that you know what you are doing here, but if you like, you can let git pull choose one. It will choose git merge by default. This means you get all of the complications of git merge and none of the complications of git rebase.
You probably don't want complications at all. This is kind of tough, because Git being Git, you get complications. Sometimes merge will fail. Sometimes rebase will fail. This is one of the reasons I argue you should pick one explicitly: when git pull fails, you need to know which second thing it is that git pull ran that failed!
I suspect you are avoiding commits because having your own commits makes it much more likely for git merge or git rebase to fail. This is true! This is also why git stash can help. But remmber, git stash is just making commits that aren't on your branches—and this means that if you avoid a failure here, at the first two steps that git pull runs, you are just moving the point of failure to when you un-stash with git stash pop or git stash apply!
The bottom line, as it were, is that no matter what you do, you will eventually run into a problem: you will have some change you have made that conflicts with some change someone else has made.
You will have to combine these changes. This combining is an action—a verb, as it were—that Git calls merging. This merge-as-a-verb, this action of merging, happens with both git merge and git rebase, and it also happens with git stash apply (which is the first half of git stash pop).
There is nothing wrong with doing this via git stash, but you will eventually have to learn how to do it. Once you know how to do it, you can also do it with git merge or with git rebase. To do merging in Git, you will want to use commits, whether those commits are those made by git stash, or by yourself running git commit. So don't be afraid to commit! You can put this off as long as you like, of course—and using git stash before pull can make this easier—but remember that git stash is making commits, and git pull is running merges!
