You shouldn't do this. It's recommended to have bare repositories. In other words, no files checked out, just the .git directory itself. You can then checkout the repository to some other location on your server -- say, your web root. This way, you get:
git best practice. According to the Git docs, you can get "unexpected results" if you don't follow it. Anyone who's done a good bit of programming knows that "unexpected results" is code for "will probably eat your children and should be avoided at all costs."
better security, if you're planning to have the checked out files on the server accessible from a webserver.
Local modifications on your checked-out code, and the ability to make quick changes on the live checked out code. You could attempt to do this directly on the repository, but it would be messy and more prone to error.
The ability to update your server repository independently of updating your live service code. This is pretty crucial, if you're working remotely and need to send something to the server and then do further work before it will be ready for your live service, or if you have changes in your live service code (say, different configuration settings) and need to merge those changes with the changes in the repo, but can't do it just now.
I'd recommend the following steps:
- Follow the git docs on setting up a bare repository
- Check out code from your repo to your live service target dir
- Setup a git hook (post-commit should be the right one IIRC) to update your live service when the repository is updated. It should probably cd to the live service dir, and do a git pull --rebase, and maybe set some file permissions.
- Just push your code to the repo from your dev box from now on.