Git: recommended setup for web development_问答_开发者

For two weeks now I've been trying to implement Git at our office. Rather than lack of documentation it's the wealth of examples, tutorials and the various uses of git that have made me confused as to what is a recommended setup for web development.

I think I have a decent setup in mind, but before diving into yet another structure, I'd like to check with more experienced people. I have the following in mind:

Workstations push to a local staging server (A)
Local staging server works with gitolite to properly divide roles
A hook automatically pushes any change to the staging server onto the production server (B)

This is visualized below:

Git: recommended setup for web development

Does this make sense? We have a variety of smaller PHP websites, nothing very complicated. The doubts I have are:

What kind of 'hook' should I use for (B)?
Should I also run gitolite on the production server? I feel I should not, because after all it is just one user that uploads things to the server (the hook on the staging server), but I'm not sure.
My starting point is: we have all websites on the Production server, and not yet on the Staging server nor the Workstations. What is a convenient way of "pulling" them down to staging and workstations, at the initial setup?

Now, the following questions are some extra thoughts, not of utmost important at the moment but share your thoughts if you happen to know more:

For simplicity I prefer to be able to run git push from the workstation and have both the staging server and production server updated. But sometimes it might be useful to only update the staging server and check out things over there first, before going live. Is there an easy solution?
In reality we have not only one but several different production servers. But only one staging server. Is there a way of configuring different production servers so that git automatic开发者_Go百科ally pushes them out to the right server?

Thanks in advance for sharing your thoughts!

What kind of 'hook' should I use for (B)?

You should use the post-receive or post-update hooks to do that

Should I also run gitolite on the production server? I feel I should not, because after all it is just one user that uploads things to the server (the hook on the staging server), but I'm not sure.

Not mandatory for the reasons you've mentioned, but since gitolite is pretty simple to setup it won't hurt

My starting point is: we have all websites on the Production server, and not yet on the Staging server nor the Workstations. What is a convenient way of "pulling" them down to staging and workstations, at the initial setup?

For each of them you can simply execute these commands

cd /path/of/project
git init
# optionally create and edit your .gitignore file before the next step
git add .
git commit

and then from your staging server run a git clone command.

For simplicity I prefer to be able to run git push from the workstation and have both the staging server and production server updated. But sometimes it might be useful to only update the staging server and check out things over there first, before going live. Is there an easy solution?

I can't see an easy solution for this task, however I don't like your solution with automated production deployment, something could go bad and you'll break your production site, so I prefer citizen conn multiple remote solution. You can manage things better with gitolite and permission handling. Everybody can push on staging server but a restricted group of people can push to production server.

In reality we have not only one but several different production servers. But only one staging server. Is there a way of configuring different production servers so that git automatically pushes them out to the right server?

You could store your production server address in some text file in the project and then use the content of that file in your git hook.

You don't want to run a git server on your production web server. And you really don't want your git repository files on your production server either. Personally I like to keep things simple and not mix up my deployment process with my SCM process.

So I guess I'm not going to answer your question about git, but I do use git for all my web projects, and here's the type of deployment setup I use:

I usually use git only for SCM, and use an internal server to host the repositories (this could very well be the same machine as the staging server).

For deployment, I usually use a rake script, since I like ruby. But a bash script would do just as well. The bash version would be something like this:

# deploy_staging.sh
rsync -va --delete --exclude-from excludes.txt ./ stagingserver:/htdocs/www.mysite.com/

# deploy_prod.sh
rsync -va --delete --exclude-from excludes.txt ./ realserver:/htdocs/www.mysite.com/

# deploy_all.sh
bash deploy_staging.sh || exit $?
bash deploy_prod.sh

# excludes.txt
.git
deploy_*.sh
excludes.txt

Developers that are authorized to publish to the servers have their SSH keys added to appropriate accounts on the server machines.

Nice and simple, easy to replicate, no messing around with setting up hooks, and everything is nicely contained in the repository, you have clear control over what gets deployed, and you can check it out and run deploy from anywhere that has the right network access.

I have a similar setup and I prefer to use multiple remotes. So instead of using a hook, I would add "prod" as a remote and also add "uat" as a remote. That way if I want to push to production, I can do: