[snprbob86]

> There may be situations where you want the entire history of your development to be included on your live server, but often this just isn't appropriate.

Are you concerned about being wasteful with disk space? Or is there some other concern here? Some security issue perhaps?

[ohwp]

I once committed my DB settings (Mercurial) and noticed my mistake only later. It's very hard to get it out of the history. Ofcourse it could be fixed but this is one example.

Imho version control could be used for deployment but only when you use the release-branch of your project.

And ofcourse NEVER put your config in version-control ;)

[mnutt]

And of course NEVER put your config in version-control ;)

I'm not sure I'd make that blanket statement. Version control seems like a great place for configuration. It allows you to centrally manage configuration details and provides an audit trail for debugging. You just want to make sure it is in a separate, secure repository and not mixed in with your app development.

[jlgreco]

FWIW, removing things from history entirely is easy with git using git-filter-branch. The real problem is realizing that you need to do that in the first place.

[scott_w]

I want to reinforce what mnutt said. A separate, secured repository for your settings is a very good thing.

You may want to look into salt, chef or puppet, which let you separate out your configuration from your security credentials.

[jwilliams]

I'm sure many people have done this - the most prudent thing would be to change the sensitive settings? That would solve your history problem as well.

[rdtsc]

> And ofcourse NEVER put your config in version-control ;)

Why wouldn't you want to version your configurations in general? Maybe I am not sure what you mean by "config" but in general version controlled configuration is always good. I even set up git in my etc sometimes to track changes I make to it manually (not in production, on my home machine).

[bpatrianakos]

I think what everyone is getting at here is to be smart about when to use git for deployment. Rsync is great for small static sites the same way git is. Now, I'm not going to use it on my medium to large size web app (actually I do for the testing server but that's another story). It's just another way to get a site deployed. I think its great for small static sites and prefer it over rsync for no other reason than I'm already using git and its just an extra git push when I'm ready. I actually use different remotes for deployment rather than a branching strategy.

[tux1968]

Both reasons.

Mostly it's because it seems people are using Git to deploy without a good reason. At least I haven't heard of an advantage enjoyed by those using Git for deployment.

There are some obvious disadvantages, so what is the compensation? It seems the only reason is that it's easy to type "git push". But of course any deployment method can be wrapped in an equally easy script command.

Okay, I have to admit to knowing of one advantage, and that is that only the delta of your changes will be transmitted over the wire, rather than a complete checkout. It's just that in practice the savings aren't usually enough to warrant the potential downsides. For my money i'd prefer rsync or any number of other solutions.

[mnutt]

The way we have it set up in capistrano, git is used as the distribution mechanism. It offers a lot of flexibility in that you can deploy a tag or a revision hash or whatever without having to worry about consistencies between users' machines or having to deal with an external packaging machine.

Once the repo has been fetched, we just check out the right tag/revision and do a local copy from the git repo into the app directory. At this step you can exclude .git if you want.

This process has an advantage over direct git checkout in that if you (heaven forbid) ssh onto the server and directly modify anything, you won't end up with conflicts.

[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?