Git – Alternative to Shelveset in TFS

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major changes. This can be adopted easily by new developers that join your project.

Besides, branching is useful even if you are working solo. For instance, you find a bug while in the process of coding a new feature. If you don't use branches, you will have to do both: add new features and fix the bug in the same branch. This is not good :P On the other hand, if you had created a new branch for creating your new feature, you can just checkout the development branch, fix the bug, and checkout back the new feature branch.

This is just a brief example of what you can do being a sole programmer. I am sure there must be more good practices.

I highly recommend you this article: A successful Git branching model

I deal with both of your proposed solutions daily. There are two key concepts to handling them well.

1. Use topic branches. I believe production history should be pristine. As a result I spend a great deal of time making my production branch's history logical, replicable, and debuggable. When using multiple machines, however, you occasionally need to commit work in progress. Use a topic branch. You can pull and push this branch from both machines with little effort, and when it's ready to merge into master or production rebase it to create a more maintainable history.
2. Using one repo shared over a network is fine, unless you're also sharing it with other users. We use a shared repository for scripts, creatively named the scripts repository. At first it seemed like a good idea as the repo doesn't change often, but over time it's become quite a nightmare. It's easy to overwrite one another's work, and you end up spending as much time air traffic controlling who's deploying the repository as you do working in it.

The best solution is keeping a local repository on each machine and sharing topic branches between them via a remote. Commit work in progress to those branches as often as you'd like. As long as you're willing to rebase them into a more intelligible history, it's quite effective in practice.

If you find yourself working on more than one topic branch throughout the day but don't want to push each one individually to the remote, git push <remote> will by default push all matching branches to <remote>. This default will change in a later version of git, but can be overrode by setting push.default in a configuration file or by specifying the matching refspec:

git push <remote> :