我的方法是在我的部署服务器上有一个裸露的Git存储库，我在那里推送更改。然后我登录到部署服务器，更改到实际的web服务器文档目录，并执行git拉取。我没有使用任何钩子来自动地做这个，这似乎比它的价值更麻烦。

从本质上讲，你所需要做的就是:

server = $1
branch = $2
git push $server $branch
ssh <username>@$server "cd /path/to/www; git pull"

我在我的应用程序中有这些行，作为一个名为deploy的可执行文件。

所以当我想要部署时，我输入。/deploy myserver mybranch。

我们使用capistrano来管理部署。 我们构建capistrano以部署在登台服务器上，然后与我们所有的服务器运行rsync。

cap deploy
cap deploy:start_rsync (when the staging is ok)

使用capistrano，我们可以在出现bug时轻松回滚

cap deploy:rollback
cap deploy:start_rsync

我的方法是在我的部署服务器上有一个裸露的Git存储库，我在那里推送更改。然后我登录到部署服务器，更改到实际的web服务器文档目录，并执行git拉取。我没有使用任何钩子来自动地做这个，这似乎比它的价值更麻烦。

git配置——local receive.denyCurrentBranch updateInstead

在Git 2.3中添加了一个很好的可能性:https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

您在服务器存储库上设置它，如果工作树是干净的，它也会更新工作树。

在2.4中有进一步的改进，包括push-to-checkout钩子和未出生分支的处理。

示例用法:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

输出:

a
b

这确实有以下GitHub公告中提到的缺点:

Your server will contain a .git directory containing the entire history of your project. You probably want to make extra sure that it cannot be served to users! During deploys, it will be possible for users momentarily to encounter the site in an inconsistent state, with some files at the old version and others at the new version, or even half-written files. If this is a problem for your project, push-to-deploy is probably not for you. If your project needs a "build" step, then you will have to set that up explicitly, perhaps via githooks.

但是所有这些点都超出了Git的范围，必须由外部代码来处理。因此，从这个意义上说，这和Git钩子一起是最终的解决方案。

不要在服务器上安装git或复制。git文件夹。要从git克隆版本更新服务器，您可以使用以下命令:

git ls-files -z | rsync --files-from - --copy-links -av0 . user@server.com:/var/www/project

您可能必须删除从项目中删除的文件。

这将复制所有签入文件。Rsync使用的是安装在服务器上的SSH。

你在服务器上安装的软件越少，他就越安全，管理它的配置和记录它就越容易。也不需要在服务器上保留一个完整的git克隆。这只会使正确地保护所有内容变得更加复杂。