我强烈建议您设置Capistrano—第一次需要做一点前期工作，但之后您可以轻松地将其用于新设置。

主要优点是

能够从桌面部署。这听起来可能不多，但通过ssh连接到远程服务器，并执行git拉入操作仍然是一件很麻烦的事。如果您需要能够执行一些很酷的操作，例如安装部署到登台/生产环境，则可以轻松回滚到以前的版本我正在添加一组capistrano脚本，向您展示我是如何设置的。

Capfile

require \'railsless-deploy\'
load \'config/deploy\'`

set :stages, %w(production staging local)
set :default_stage, "staging"
require \'capistrano/ext/multistage\'

set :application, "" # your application name - used to set directory name

set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg git@github.com:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# makes capistrano ask for sudo password or other remote inputs
default_run_options[:pty] = true

namespace :tasks do
    task :fix_links  do
        run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
        run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
      run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
      run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
      run "sudo chown -R www-data.www-data #{release_path}/"
    end
end

after "deploy", "tasks:fix_links"

config/local.rb

server "", :app  #hostname
set :branch, \'develop\' #choose branch to deploy
set :use_sudo, false #don\'t use sudo

set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy to

这是我第一次使用Capistrano和WordPress的教程：http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

实际上我做了一个关于这个主题的WordCamp演讲。与其重复我自己，here\'s a screencast of it 和here\'s a very simple deployment script 和我讨论的内容一起。

简而言之，我使用GitHub托管repo，并使用webhook根据git参考部署更改Vincent Driessen\'s git branching model 并为您提供了无限的Webhead、暂存服务器、测试服务器等，所有这些都具有自动部署功能。我还介绍了保持wp配置。php受版本控制，同时维护单独的开发/生产版本（通过重命名文件和符号链接）。

我知道这个问题有点老，但由于我在这里没有看到这个答案，我想分享一下我通常对基于git的单站点设置和部署所做的工作，它工作得非常好，还可以从多个设备、地点和多个开发人员处工作（所有人都有自己的本地repos，因为这对于git来说很常见）。

我可以诚恳地建议以下设置：

• A web-focused Git workflow (by Joe Maller; Nov 2008)

• Using Git for Deployment (by Dan Barber; Apr 2011)

将网站放在git下的实时主机上，创建一个新的bare git repository 在实时主机上当工作完成后，您将推动从中克隆的远程裸机回购。裸回购有挂钩与实时回购同步（在上述代码中称为prime）。

作为repo中Wordpress的特定设置，我有以下内容.gitignore:

# uploads are data, excluded from source tree
wp-content/uploads/

这对我的大多数Wordpress需求都很有效。裸回购协议可防止您推动相互冲突的更改。它还可以在更新实时站点之前先同步到远程副本。这意味着，更新实时站点通常相当快。由于这些挂钩，如果您愿意，您甚至可以在以后调用Wordpress更新挂钩。

如果我没有试验过使用Github挂钩可以改进多少，但我通常不需要它们，因为代码是在本地版本控制下的，而不是在Github下。

要首次设置这样的系统，您应该花一些时间来评估远程主机上是否有所有可用的工具：

SSH访问GIT是一个私有目录，您可以将文件和子目录放在其中（例如，对于您的裸GIT repo），第一次安装时间应在一到两个小时内，包括整个环境和您的首次发布推送。

根据主机的不同，您可能还希望屏蔽.git web access中的目录。下面是一些示例.htaccess 甚至将Wordpress放在子目录中这样做的代码，这会在repo中留下未在线发布的空间（有用）：

Options -Indexes

# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\\.git(.*)$

# mask 403 on .ht* as 404
<Files ~ "^\\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

如果你对托管有更多的控制权，你可以在这里做更多的事情（并且不同/更优化），上面的例子针对的是典型的共享托管环境（提供GIT的，一些用户说你也可以轻松地自己安装，我通常会要求我的托管者提供这样的服务，因为我更希望他们能注意，这是我付钱给他们的）。

从消极的方面来看，这有一些常见的问题，在其他答案中也有概述。有一件事我并不自豪，但有效的方法是让开发主机更改其主机文件，使数据库服务器指向开发副本。因此，您可以保留一个数据库配置。不是很酷，尤其是因为证书。

自动备份

mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git  : git gc
       git bundle
files: tar --force-local -czf %s %s

支持团队合作另一个好处是您的站点已经支持团队合作。由于额外的裸回购，您不会犯太多错误，甚至可以与同事共享主分支或活动分支之外的远程分支。