[RussianCow]

What are the potential downsides? I've been deploying with Git for over a year and am interested in learning why it's not a good idea.

[Marc_Paradise]

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.

[zzzeek]

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.

[kyrias]

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.

[Peaker]

"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

[michaelmior]

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

[eru]

Change the old passwords?

[Peaker]

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

[eru]

Shouldn't you audit all commits in any case?