Having a web project on a webserver shared by some developers, drives me to set up Git repo for that project.
But I still have some doubts about how to organize it.
Let’s assume I have my web projects in /var/www/
Some questions, ideas I’d like to receive comments:
Is it better to init the git repository in the same publication folder, or create /var/repo/, copy contents inside and init repos in these copies of project?
In the first case may I branch the project as a superuser and let people work on this branch… then decide to merge branches once tested? But in this case I don’t think people
could test their work easily on the webserver… they should need a local env. set up for testing.
If I create the /var/repo/domain.com, it would be nice to create Vhosts like http://git.domain.com to let developers test their committed work.
If I have the /var/repo/project.com and like to publish the committed work (e.g. copy the files to /var/www/project.com), how should I perform this copy action? With cp -R? Is there already a tool to perform this update when needed?
First of all you really shouldn’t make your web project the repository itself. First you should setup a repository for everybody to access. You can have a master and a development branch and everybody could also have own branches for special parts of the web application. The best solution is to have your repository on a different server than your live system.
If you don’t want to test things locally you should set up a development/staging server so people can test things there.
The best procedure is to use a deployment script for that, e.g. Capistrano.
Your procedure should be like that:
Server A: Repository with a master and a staging branch + other branches if needed for the development.
Server B: Live System (you can use capistrano to deploy the master branch here – if you want to be the only one who is able to deploy to the live system you shouldn’t add any ssh key to the server but yours or use another authentication method)
Server C: Testing environment (could also be on the same server like your repos but I personally prefer this separated as well)
Now use capistrano to link the live system with the master branch and the testing system with the dev/staging branch. People should have ssh access to the staging server of course.
They can push their changes to the repository using the dev/staging branch. After that they can use ‘cap staging deploy’ for deploying the dev/staging branch to the dev server to test their work.
If everything works you can simply pull the dev branche and checkout the master. Use ‘git merge staging’ to merge the dev/staging branch into the master and push it into the master repository. Afterwards a ‘cap production deploy’ would install everything on your live system.
It’s pretty easy to setup – just a few config things to do for everybody and you would have a great workflow.
Hope it helped.