Git "Live Server" Best Practices

Question

My partner and I have been dabbling with the idea of pushing and pulling from a repo that affects files viewable by the general public as opposed to storing the repos in a hidden location and just FTPing files when we feel they're good to go. While being able to directly push to the "live site" would be extremely convenient, I'm wondering what negative repercussions (if any) this would incur.

Thanks a lot!

Dani

Answer 1

I would recommend pulling rather than pushing if going this route.

Always pull the finished product and do not do merges on the live server, for if there are conflicts you will be scrambling to fix them. Do all your merging, etc on your testing environment. Once all is good there, push the finished results to your 'bare' repo for the production branch and then from the production machine git pull from it.

Yes it could be another point of failure however I think the benefits outway the cons.

Neysa

Thanks for your response. Is this process something you do often? – Dani

Yes, I typically develop locally in 'develop' branch, then push to the bare repo. Then from the testing server I pull 'develop' make sure all is good. Then merge into 'master' and push 'master' back to the bare repo. Login to the production server and pull 'master'. No ftp required and everything just works. – Neysa

Answer 2

A VCS isn't supposed to be a deployment tool (see Using git below web root in production.): a simple ftp of one file (created with git archive) would be enough.

If you want to use Git, use a bare repo on the server side to push to, and a post-receive hook to update a working tree which would represent your site.

Adrieneadrienne

There is a trend building towards using git in this way. The first one I saw was the blog engine Marley (github.com/karmi/marley), and now there is Wheat (github.com/creationix/wheat) which is based on the idea of pushing new blog posts with git. I'm also in the process of changing my website to do the same thing. Granted in all cases the use case is a blog, which is different from a webapp. Whether a VCS should be used this way is one thing, but it's true that git is increasingly being used in this way. – Belter

@Matt: sure, that's why I completed my answer with an actual way to do just that. – Adrieneadrienne

I have just been getting into a new way of using git as a "database" for collaborative scientific authoring. It is working great. Git is a tool. And just like any other it is worth evaluating based on its unique capabilities. Imagine you wanted to make a large collaborative wiki and back it with a git database, serving the files directly from git could offer deployment advantages. – Delivery

@orangutancloud: a bit like Hatta Wiki (using Mercurial: hatta-wiki.org) or other similar projects? (hatta-wiki.org/Similar%20projects): git-wiki (github.com/sr/git-wiki) – Adrieneadrienne

to get to the point, let's say your flat file wiki grows to 10 mb, with git archive as I understand, your FTP to each deployment server would be 10 mb for every change. If you were using git to deploy each update would just be the size of the changes, unless I misunderstand the capabilities of git archive – Delivery

@Adrieneadrienne yeah, that looks quite cool. It seems like you have a good point though about worrying which services to start / restart. So for deploying code it may not be a solution, but for collaborative data it offers interesting possibilities – Delivery

@orangutancloud: yes, I don't disapprove using Git in this instance, I just mention the larger point of "deployment" which isn't only about transferring files ;) – Adrieneadrienne

Thanks a lot for the references and the resources, and I never knew about Git archive. So much to learn about Git, but so little time. – Dani

Answer 3

It sounds like you are a candidate for scripted deployments. I would highly suggest looking into Capistrano and Webistrano. With these tools, you can deploy from a publicly available git repo easily and update only the code necessary on the server. A cached copy of the repo is held on the server, so you are only transmitting the change sets. The two tools I mentioned also allow you to easily roll back changes, manage database migrations, etc. Webistrano is essentially a web front-end to Capistrano, which is a ruby gem. I've also heard good things about Vlad, but I'm not as familiar with it. Best of luck.

Signor

Answer 4

I "Push" my local development to the Live Server this way:

1.- Configure a hook on the server .git/hooks/post-receive
including this lines:

     git pull
     git reset --hard

Warning: reset --hard will remove any changes on the live workspace. (See below)

2.- Give Executable rights to the file

 chmod +x .git/hooks/post-receive

3.- Allow the "non-bare" repository on the live server to receive the Push

 git config receive.denyCurrentBranch ignore

I work on my local copy (for development), which was cloned directly from the live server. and deploy by just

 git push 

In order to avoid conflicts I have the convention of: Always Pull before pushing Never work on the live site or commit on the server.

I hope you find this method useful.

Artilleryman