总结

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

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

问题的解剖

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

So

A ← B
    ↑
[HEAD,branch1]

就变成了

A ← B ← C
        ↑
    [HEAD,branch1]

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

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

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

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

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

因为已经有一个现有的存储库正在运行

git config --bool core.bare true

在远程存储库上就足够了

从核心开始。裸露的文档

如果为true (bare = true)，则假定存储库是空的，没有关联的工作目录。如果是这种情况，许多需要工作目录的命令将被禁用，例如git-add或git-merge(但您将能够推到它)。

在创建存储库时，git-clone或git-init会自动猜测该设置。默认情况下，存储库以“/”结尾。Git”被假设为非裸(bare = false)，而所有其他存储库都被假设为裸(bare = true)。

这对我很有用

git配置——global receive.denyCurrentBranch updateInstead Git push origin master

我有这个错误，因为git回购(意外地)初始化两次在同一位置:第一次作为一个非裸回购和不久之后作为一个裸回购。因为.git文件夹仍然存在，所以git假定存储库是非裸的。删除.git文件夹和工作目录数据解决了这个问题。

当我在阅读progit时，我得到了这个错误。我创建了一个本地存储库，然后在同一文件系统上的另一个repo中获取它，进行编辑并尝试推送。在阅读了NowhereMan的回答后，一个快速的解决方法是转到“远程”目录并临时签出另一个提交，从我所做更改的目录中推送，然后返回并将头部放回master。

在另一篇文章中解释这个问题。 在我看来，更好的做法是:

对于远程服务器中的存储库:git branch -b work, work是一个专门用于远程服务器的工作分支。 将本地提交推到远程服务器，本地分支的名称(dev)应该与work不同，以避免混乱，现在git Push origin dev不会出现错误。 合并开发以在远程服务器中工作。git合并。