On Mon, Jul 23, 2012 at 12:23 AM, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote: > On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> merlyn@xxxxxxxxxxxxxx (Randal L. Schwartz) writes: >> >>>>>>>> "Darek" == Darek Bridges <darek.bridges@xxxxxx> writes: >>> >>> Darek> I use git for many things, but I am trying to work out the >>> Darek> workflow to use git for deployment. >>> >>> Don't. >> >> Yeah, "don't think 'git checkout' is a way to 'deploy'". Using Git >> as a transport measure is probably fine. > > You can also try > http://sitaramc.github.com/the-list-and-irc/deploy.html. Whether it's > saying you *can* use git for deploying something, or you *can* but > *should not*, or you *cannot*, will depend on your own thoughts on the > matter ;-) After a couple of false starts, I think that Sitaram came closest to what Darek was asking about. Now, as somebody who is using Git currently to stage things to "deployment" (I may change to SVN due to office politics--which will double my workload on rollout of updates, but I'm not saying any more than that in public) on production web servers, I have a few comments. We have several WordPress instances @$work where we are using Git to stage template changes out to our development server (where I've contemplated putting the lessons in Sitaram's article to use) before merging those changes back into the "Production" branch (after suitable testing) and pulling them from a central gitolite into the live server. It works and it respects the posix extended ACLs on the destination host (which is what you actually want on a live web server). Even better, it provides a safe way of tracking and merging back in any "opportunistic" changes that were made directly in the development or production servers so that they are not lost. Thought must be applied to do this safely, but that's the way it usually is on web servers. To those who say admins should be using RPM, DEB, or any other "generic package management" software to deploy non-system updates to in-house web servers may I kindly indicate that it often doesn't make sense to do so unless each and every website has its own server and IP address--and you are deploying tens of thousands of them. Most of us can't afford that. (Yes, there is an overhead to building packages. I've done it enough times to know about that quite intimately.) Packages and package management are great for system software but they are not a good solution for installing client code into a webspace on a shared server (yes, heresy, I know). For this common use case Git is not a half-bad ADDITION to the toolkit of a website development and maintenance team. -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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