只需几个设置步骤，您就可以轻松地使用一行程序部署更改到您的网站

git push production

这很简单，你不需要登录到远程服务器并进行拉取或其他操作。请注意，如果您不将生产检出用作工作分支，这将是最好的工作方式!(OP的工作环境略有不同，我认为@Robert Gould的解决方案很好地解决了这个问题。此解决方案更适合部署到远程服务器。)

首先，你需要在你的服务器上的某个地方建立一个裸库，在你的webroot之外。

mkdir mywebsite.git
cd mywebsite.git
git init --bare

然后创建文件hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

并使文件可执行:

chmod +x hooks/post-receive

在本地机器上，

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

都准备好了!现在，将来您可以使用git push production来部署您的更改!

这个解决方案的功劳归http://sebduggan.com/blog/deploy-your-website-changes-using-git/。在那里可以找到关于正在发生的事情的更详细的解释。

我也有同样的问题。对我来说，我使用Git push将代码移动到服务器。我从不改变服务器端的代码，所以这是安全的。

在存储库中，您正在按下输入:

git config receive.denyCurrentBranch ignore

这将允许您在存储库是工作副本时更改存储库。

运行Git推送后，转到远程机器并键入以下内容:

git checkout -f

这将使您所推动的更改反映在远程计算机的工作副本中。

请注意，如果在您要推入的工作副本中进行更改，这并不总是安全的。

错误消息error: refused to update检出branch: refs/heads/master由远程存储库发出，这意味着您试图将代码推到远程非裸存储库，该存储库当前在工作目录中检出了不同的代码。避免此问题的最佳方法是只推送到裸存储库—裸存储库永远不会发生此问题。

您可以简单地将远程存储库转换为裸存储库(裸存储库中没有工作副本—文件夹只包含实际的存储库数据)。

在远程存储库文件夹中执行以下命令:

git config --bool core.bare true

然后删除该文件夹中除.git外的所有文件。然后你就可以执行git推送到远程存储库而不会出现任何错误。

以防有人觉得有用。对我来说，这是一个git服务器权限问题。我检查了项目从乞求和推送一个简单的文件，然后我得到“推送拒绝:推送到原点/主被拒绝”

例如，一旦创建了空(裸)存储库，就需要更改远程服务器上的配置文件

root@development:/home/git/repository/my-project# cat config 

你会看到

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

你将使这裸露为假为真，我删除了logallrefupdates = true(不确定它的使用!)

to

[core]
repositoryformatversion = 0
filemode = true
bare = true

您可以测试以下内容

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

这个HEAD分支:(未知)将显示如果你不能PUSH。因此，如果HEAD分支是未知的，你应该将bare更改为true，在推送成功后，你可以重用

git remote show origin

你们会看到

 HEAD branch: master

您可以通过在目标服务器上编辑.git/config来绕过这个“限制”。添加以下命令，允许git存储库被推入，即使它被“签出”:

[receive]
denyCurrentBranch = warn

or

[receive]
denyCurrentBranch = false

第一个将允许推送，同时警告可能会弄乱分支，而第二个将只是静静地允许它。

这可以用于将代码“部署”到不用于编辑的服务器上。这不是最好的方法，但对于部署代码来说是一种快速的方法。