On Jan 17, 2008 6:42 PM, Mike <fromlists@xxxxxxxxxxxxxxxxx> wrote: > With PHP, Python, and Ruby, the development is the deployment. The Plenty here use git for web apps. > There's a fundamental "best practice" of web development being violated > here- keep your docroots clean, only put stuff in them that should go > live (or should eventually go live when ready). Other files should not > live under docroot. *First* - people here have pointed out various ways of doing this with the GIT_DIR env variable. Nothing is being violated. In terms of the best-practice you mention of publishing only the reachable files, your checkout is one directory higher. The top-level dir of your checkout should look like: .git htdocs # this is published conf # configuration files lib # libraries if you publish the top of your checkout, your libraries sit in there. Along your .git and your config files. > Among the reasons for that is security. If one of those .git dirs does > slip out and go live, it's a *huge* *gaping* *security* *hole*. You Well -- I routinely add .git CVS and .svn to http.conf with a directorymatch clause to prevent access to them. Just in case, belts-and-suspenders. > If we end up having to write a special "publisher" app to move files > from dev to live, then it will only be because of those damn .git > directories. Nah! It'll be because of a long list of things, including temp files, backup files that developers make, all sorts of things in your *work* dir that you really need there and you really should _not_ have in the production checkout. BTW, I also add common patterns for those temp files to httpd.conf to restrict access to them. > Maybe git just isn't intended to be used for anything besides compiled > languages like c? Or maybe just not for web app development? C produces a ton of intermediary files that git never commits, and C projects usually get an "installer" too (debian's apt/dpkg, rpm, etc). Writing PHP/Ruby/Python produces less "intermediary" files, but it still creates some, so there's plenty of good reasons to have an "installer". GIT does the SCM thing, but for handling your deployment you need something else. I normally use scripts that use git internally, written in make, perl or shell. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
