下面是一个测试，你可以看看裸服务器的东西是如何工作的:

想象一下，您有一个工作站和一个服务器，服务器上托管着活动站点，您希望不时地更新这个站点(这也适用于两个开发人员通过一个中间人来回发送他们的工作的情况)。

初始化

在你的本地计算机上创建一个目录，并将cd放入其中，然后执行以下命令:

# initialization
git init --bare server/.git
git clone server content
git clone server local

首先创建一个裸服务器目录(注意末尾的.git)。此目录将仅作为存储库文件的容器。 然后将服务器存储库克隆到新创建的内容目录。这是您的活动/生产目录，将由服务器软件提供服务。 前两个目录位于您的服务器上，第三个是您工作站上的本地目录。

工作流

下面是基本的工作流程:

进入本地目录，创建一些文件并提交。最后将它们推送到服务器: #创造疯狂的东西 Git提交-av Git push origin master 现在进入内容目录并更新服务器的内容: git拉 重复1 - 2。这里的内容可能是另一个开发人员也可以推送到服务器上的，并且您可以从他那里获取本地内容。

错误消息描述发生了什么。更现代的Git版本在分支签出时拒绝通过推送更新该分支。

在两个非裸存储库之间工作的最简单方法是

总是通过pull(或fetch和merge)来更新存储库，如果必须的话， 通过推入到一个单独的分支(导入分支)，然后将该分支合并到远程机器上的主分支。

这个限制的原因是推送操作只能在远程Git存储库上操作，它不能访问索引和工作树。因此，如果允许的话，对签出分支的推操作将使HEAD与远程存储库上的索引和工作树不一致。

这将非常容易意外地提交一个更改来撤销所有已推送的更改，也使得很难区分尚未提交的任何局部更改和新HEAD、索引和工作树之间的差异，这些差异是由推送移动HEAD引起的。

你有三种选择

又拉又推: git拉;git推 推入不同分支: Git push origin master:foo 并在远程合并它(通过git或pull-request) Git合并foo 强制执行(不推荐，除非你故意通过rebase改变提交): Git push origin master -f 如果仍然被拒绝，禁用远程存储库上的denyCurrentBranch: git config receive.denyCurrentBranch ignore

我刚开始学习Git时也犯过同样的错误。其他一些答案显然不适合Git新手!

我要用一些非专业术语来表达我的意思。不管怎样，你有两个存储库，一个是你第一次做的原始的，另一个是你刚刚做的工作。

现在您在工作存储库中，正在使用主分支。但是您碰巧也在原始存储库中“登录”到同一个主分支。现在，由于您是在原始版本中“登录”的，Git担心您可能会搞砸，因为您可能正在使用原始版本并把事情搞砸。因此，您需要返回到原始存储库并执行git检出其他分支，现在您可以毫无问题地进行推送。

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

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

git config receive.denyCurrentBranch ignore

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

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

git checkout -f

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

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

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

[receive]
denyCurrentBranch = warn

or

[receive]
denyCurrentBranch = false

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

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