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

[receive]
denyCurrentBranch = warn

or

[receive]
denyCurrentBranch = false

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

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

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

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

git config receive.denyCurrentBranch ignore

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

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

git checkout -f

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

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

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

[receive]
denyCurrentBranch = warn

or

[receive]
denyCurrentBranch = false

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

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

我不得不在一个现有的裸库中重新运行git——init，这已经在裸库树中创建了一个.git目录-我意识到在那里输入git状态后。我把它删除了，一切又恢复正常了:)

(所有这些答案都很棒，但就我而言，我的情况完全不同(据我所知)。)

你有三种选择

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

总结

您不能推送到存储库的一个签出分支，因为这会扰乱该存储库的用户，很可能以丢失数据和历史记录而告终。但是您可以推送到同一存储库的任何其他分支。

由于裸存储库从来没有检出过任何分支，所以您总是可以推入裸存储库的任何分支。

根据您的需要，有多种解决方案。

解决方案1:使用裸存储库

正如建议的那样，如果在一台机器上不需要工作目录，则可以移动到裸存储库。为了避免混淆存储库，你可以克隆它:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

现在你可以把所有你想要的推送到和以前一样的地址。

解决方案2:推到一个非签出分支

但是如果您需要检出remote <remote>上的代码，那么您可以使用一个特殊的分支来进行推送。假设在本地存储库中，您已经调用了远程源，并且处于分支master上。然后你就可以

machine2$ git push origin master:master+machine2

然后你需要合并它当你在原始远程回购:

machine1$ git merge master+machine2

问题的解剖

当一个分支签出时，提交将添加一个新的提交，当前分支的头作为其父，并移动该分支的头作为新提交。

So

A ← B
    ↑
[HEAD,branch1]

就变成了

A ← B ← C
        ↑
    [HEAD,branch1]

但如果有人可以推送到中间的那个分支，用户就会进入git所说的分离头部模式:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

现在用户不再在branch1中，没有显式地要求签出另一个分支。更糟糕的是，用户现在在任何分支之外，任何新的提交都会悬空:

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

假设，如果此时用户签出了另一个分支，那么这个悬空提交将成为Git垃圾收集器的公平游戏。