Security.

Are you 100% sure that there is nothing you are exposing via your git repo that you want to keep away from the person who manages to hack your server or discover some means to reach the repo externally?

Getting hacked is not inevitable, but if you treat your systems as if it were you'll be a lot safer if it does ever occur.

If you push via git or via rsync, you're typically going over SSH in both cases. As far as the .git directory, my post-receive hook also does a "cp -R" of the files to the actual web-served directory (there's a build step in between anyway), so there's no .git exposed. As far as security, as long as one knows to handle the .git directory, there's no difference.

If there's anything in your repo history that you don't want a hacker to find you can just remove it and force push.

"Just remove it" is hard, because:

* It may be hidden in some old commit (e.g: some password)

* You'd need to rewrite all history from that point

* Force push doesn't necessarily clean the data from the remote

FWIW, the "hidden in some old commit" problem is easily solvable with git-filter-branch. But the second two points are certainly valid :)

Change the old passwords?

I think the main problem is unknown exposure: Do you audit all old commits to find any sensitive data?

Shouldn't you audit all commits in any case?

So, you have two choices:

1) You can go through the trouble of identifying and resolving all the edge cases that you encounter when using Git as a deployment tool. Keeping in mind that one of those may result in an embarrassing security disclosure. Woops.

2) You can use a deployment tool that was developed for that purpose, has existed for years, and has had many sets of eyes on it; many of which are inevitably more experienced than you. And you still may end up with an embarrassing security disclosure, but the chances are better that you'll hear about it through responsible disclosure channels first, rather than waking up at 3 AM to the voice of your boss/client asking why the site is redirecting users to buy Viagra at a discount.

A bonus third choice:

3) You look at existing deployment tools and ask yourself "I wonder why they do that?" Then, maybe ask around a bit. Once you've got a good idea of all idiosyncrasies involved with deploying software, then you embark upon building your own tool. I think you'll find that simply `git pull`ing from your httpd document root and `rm -R`ing the .git/ directory won't be your final solution.

If anything you should have the webroot directory in the git repo, not have the repo be the webroot

The audit of commits in the general case (Checking for errors in the code) and the audit for the deployment case (Checking for sensitive data that may be exposed in a security breach) are different audits. I don't think many tend to do the second kind of audit.

Also, minimizing your exposure in case of a security issue is probably a good idea, so the convenience of deploying with git may or may not be worth this extra exposure.