We are a group that started working on a fairly big website with an existing codebase. We have a test and a production server. Our idea is to have a test repository with a number of devs having push access to; and a blessed repository that only a few can push to. The blessed repo is supposed to be always stable and represent the latest production version. How can I automate the process of transferring the files into production? Is it bad to have the production files under version control? That way, pushing to the blessed repository would mean deployment. But, what happens when there are merge conflicts? Will the production server break until it is resolved? 
How to transfer files to production?
git;workflows
To put it simple:The push process in itself should be fully automatic. Whether you have some custom script, or you simply pull from the blessed repo to the production environment. That is up to you. You should just have something automated, because automated processes can be made reliable (as opposed to uploading files by hand and such). However, the push process should be triggered manually. You push your updates, and once you feel confident, you tag it as a release candidate and pull it to your test environment (that would ideally be as similar to your production environment as possible). Once the RC is tested, the push can be initiated.As of today, nothing else can give you, what human testers can.This sounds a little slow, in the sense that the feedback loop is a relatively big. But for proper testing, it is important to take an fixed snapshot, which is then examined for 24-48h (or maybe more, depending on the size of the project). The opposite is a scenario, where you find a lot of bugs right after pushing and you try to patch it up with some quick fixes that introduce new bugs.You better make a release with known bugs (of acceptable severity), than one with unknown bugs (of unknown severity).