Question

I am using git to manage a dynamic website (PHP + MySQL) and I want to send my files from my localhost to my staging and development servers in the most efficient and hassle-free way.

I am currently convinced that the best way for me to approach this problem is to use this git branching model to organize my local git repo. From there, I will use the release branches to push to my staging server for testing. Once I am happy that the release code works on the staging server, I can then merge with my master branch and push that to my production server.

Pushing to Staging Server:

As noted in many introductory git posts, I could run into problems pushing into a non-bare repo, so, as suggested in this response, I plan to push the release branch to a bare repo on the server and have a post-receive hook that clones the bare repo to a non-bare repo that also acts as the web-hosted directory.

Pushing to Production Server:

Here’s my newest source of confusion…

In the response that I cited above, it made me curious as to why @Paul states that it’s a completely different story when pushing to a live, development server. I guess I don’t see the problem. Would it be safe and hassle-free to follow the same steps as above, but for the master branch? Where are the potential pit-falls?

Config Files:

With respect to configuration files that are unique to each environment (.htaccess, config.php, etc), it seems simplest to .gitignore each of those files in their respective repos on their respective servers. Can you see anything immediately wrong with this? Better solutions?

Accessing Data:

Finally, as I initially stated, the site uses MySQL databases to store data. How would you suggest I access that data (for testing purposes) from the staging server and localhost?

I realize that I may have asked way too many questions for a single post, but since they’re all related to the best way to set up this development scheme, I thought it was necessary.

Answer 1

Pushing to the production server

I assume that in the response you quote, the answer refers to pushing to the production server as “a different story”, just because one can push any old commit to the staging server for testing, but you would be very careful only to push a thoroughly tested version to the production server.

I think the approach you refer to (of deploying by pushing to a bare repository with a post-receive that does git checkout -f with an appropriately set GIT_WORK_TREE) is a good one for deploying from git.

Config Files

That is a reasonable plan, but you have to be a somewhat careful about using .gitignore to ignore configuration files – you might want to look at this answer for more about this:

• How can I have different versions of a file in the local working directory, remote working directory and git ftp target?

Accessing data

I think the question about data for your staging server really is a separate issue, since none of that data will be in your version control system – it might be worth adding another question here about that issue. You could have a script that dumps data on your live server and imports it to the staging server, but I can think of many situations in which that would be undesirable, particularly where customer details and data protections laws have to be considered.