You could also look into vagrant to set up a virtual machine to run an environment similar to production server.
Even if the initial setup might be complicated, after you have the VM done, all you have to do on a new machine is:
It's recommended to have a local dev environment. It's faster (no network can beat saving locally, no matter how fast it is!) and more reliable. Think what's happen if your connection drops for a week or two.
Now, about Git:
I have the feeling that you didn't understand branching model. It's not a branch per user, it's a branch per feature. My branching model looks like this:
• master branch. That is the secondary branch, that is in production.
• develop branch. That is main branch, where i do the work and is pushed to test server. On release day i merge it into master and push to live server. Each release also have a tag for version (like v1.2)
• countless other branches that are made for new features/bug fixes. If the change is small (one, two commits), I made it dirrectly on the develop branch. It's a normal thing to work on something big..ish and my client come and tell me „do this very quick change here”. I switch branch, do the stuff, push, then change back. Everybody is happy
Probably it's a good idea to squash commits when you merge into parent branch. If, let's say, new feature branch has 20 commits, probably you won't want to see those commits into develop branch (or when you merge develop into master).
And no, you don't need to be 100% in sync every single second with your server/co-workers (and this was one of the most dificult thing to grasp when i first started to use version control)
== edit ==
If you are a PHP developer is less likely to not have these installed already