Using git to manage a production web site?

Question

I have a web site with about 15,000 files on a production server. A remote developer is now doing the bulk of the work on the site, but I occasionally need to make some edits also. It is apparent that we need some version control, and so I am trying to set up git.

I really would like to keep the setup simple and straightforward. We don't need any sort of integrator to look over our changes - we are both fully trusted to push changes to the production site. I also don't see any need to push changes to a staging server before making them live, as there's nothing we could test there that we can't test on our local machines. I basically just want something which will keep us from clobbering each other's files. Here is the scenario I have in mind:

          Production Server
              ↗↙ ↖↘          
Developer1(LAMP)  Developer2(WAMP)

Questions:

1. Does this workflow make sense for a team of two developers (one of whom only makes occasional edits) or are there better ones?

2. Is there any advantage at all in adding a staging server in between the developers and the production server?

3. I assume the production server should be a bare repo with a post-receive hook pointing to the webroot folder, that we would clone a copy to each developer's machine, and then git commit / git push to launch any changes back to production?

4. Is there any easy way to create a bare repo on the production server and then add the site's existing 15,000 files to it? Or do I have to download them to the clone repo on my local workstation and then do git add / commit / push to get them loaded in the production server repo? (They could take almost 13 hours to upload.)

Thanks!

Answer 1

Nothing wrong with the workflow, per se. But generally the "canonical" repository is separate, and you deploy to your production server manually with some other mechanism like rsync. This way:

1. Your production server updates aren't tied to your development workflow. If your production server (ever!) needs any work done after a code change—restarting the webserver, flushing some cache, making a schema change, etc.—then suddenly production system concerns are interfering with your ability to update code and that sucks.

2. You don't have to worry about accidentally leaking access to your .git directory and exposing all your source code and development history.

3. It takes two accidents to break the site (ruin master and deploy) instead of just one (ruin master).

4. Perhaps not a concern with just the two of you, but it's useful to have the "update the site" button have different authorization than the "update the code" button.

Staging servers exist to be like production, but breakable. You only have two developers, yet you're already using wildly different operating systems; I'm fairly certain at least one of you is not using a development environment identical to production. :)

And no, you can't add files to a bare repository. You need a working copy to do anything with the working tree.