您应该只推送到一个裸露的存储库。裸存储库是指没有检出分支的存储库。如果要cd到一个裸存储库目录，则只能看到.git目录的内容。

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

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

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

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

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

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

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

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

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

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

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

git config --bool core.bare true

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

事实上，将远程设置为一个未签出的分支就足够了。当您在不同的分支签出您的遥控器后，您可以按。

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

[receive]
denyCurrentBranch = warn

or

[receive]
denyCurrentBranch = false

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

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

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

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

git config receive.denyCurrentBranch ignore

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

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

git checkout -f

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

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

您可以重新创建服务器存储库，并从本地分支主服务器推送到服务器主服务器。

在远程服务器上:

mkdir myrepo.git
cd myrepo.git
git init --bare

好的，从你当地的分公司:

git push origin master:master

我喜欢在远程机器上仍然有一个可用的存储库的想法，但不是一个虚拟的分支，我喜欢使用:

git checkout --detach

这似乎是Git的一个非常新的特性——我使用的是Git 1.7.7.4版本。

我发现一篇可能对其他人有用的文章是《Git 5分钟》。

我有一个在Git版本控制下的Xcode项目，我想把它推到DC中的虚拟分布式以太网(VDE)上。VDE运行Centos 5。

我读过的关于Git的文章中没有一篇谈到了裸库。这一切听起来都很简单，直到我尝试了我认为来自SVN背景的东西。

这里的建议使远程存储库裸露工作。更适合我的需求是克隆Xcode项目到projectname。Git，复制到远程服务器;然后，推神奇地起作用了。下一步将是让Xcode推送没有关于提交的错误，但现在我可以从终端做它。

So:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

在Xcode中提交后，从Xcode项目中推送更改:

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

我确信有一种更流畅更复杂的方法来完成上述工作，但至少这是可行的。为了让一切都清楚，这里有一些澄清: /xcode-project-directory是xcode项目的存放目录。可能是/Users/Your_Name/Documents/Project_Name。 Projectname字面上是项目的名称，但它可以是任何您愿意调用它的名称。少不更事的人不在乎，你会在乎的。

要使用scp，您需要在远程服务器上有一个允许SSH访问的用户帐户。任何运行自己服务器的人都会有这个。如果你正在使用共享主机或类似的东西，你可能就不走运了。

Remotehost.com是远程主机的名称。你可以使用它的IP地址。为了进一步清晰起见，我在远程主机上使用带有SSH密钥的giitosis，所以当我按下按钮时，不会提示输入密码。文章托管Git存储库，简单(和安全)的方式告诉你如何设置所有这些。

我在使用Git同步Android手机和笔记本电脑上的存储库时也遇到了同样的问题。我的解决方案是拉而不是推，就像@CharlesBailey建议的那样。

git在Android存储库上推送origin master失败，与@hap497得到的错误消息相同，因为推送到存储库+工作副本的非裸签出。

Git在笔记本存储库上拉droid master，并为我工作复制。当然，你需要先运行git remote add droid /media/KINGSTON4GB/notes_repo/。

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

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

初始化

在你的本地计算机上创建一个目录，并将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。这里的内容可能是另一个开发人员也可以推送到服务器上的，并且您可以从他那里获取本地内容。

最好的方法是:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

这将克隆存储库，但不会在…/remote中生成任何工作副本。如果查看远程，您将看到创建了一个名为currentrepo的目录。Git，这可能是你想要的。

然后从本地Git存储库中:

git remote add remoterepo ..../remote/currentrepo.git

进行更改后，您可以:

git push remoterepo master

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

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

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

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 branch dev
git checkout dev

在本地设置中:

git push 

远程服务器:

git merge dev

总结

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

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

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

解决方案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垃圾收集器的公平游戏。

我相信大多数看到这个问题的人会止步于前两个重要的答案，但我仍然想提供我的解决方案。

当遇到描述的错误时，我有一个Eclipse + EGit web项目设置。帮助我的是使用GitHub应用程序，它似乎神奇地解决了这个问题。虽然EGit总是拒绝推送，但GitHub桌面应用程序只会耸耸肩，推送我的更改。也许它能更优雅地处理多次登录的情况。

我的解决方案(正在使用中)

在远程服务器上签出“master” 在“开发”部门工作 将更改推送到远程开发人员 在远程上将开发人员合并为主机

宾戈游戏

我的解决方案是:

在远程:

git checkout -b some_tmp_name

地方:

git push

在远程:

git checkout master
git branch -d some_tmp_name

但这不是真正的解决方案，这只是一种变通方法。

我刚刚在Heroku上部署git存储库时遇到了这个问题。

我不知道为什么Heroku在他们的一方有一个非裸库，但作为一个变通办法，我能够重置远程库，并重新加载。

你不应该使用Heroku的存储库副本作为你唯一的git存储库进行协作，但为了以防万一，我要明确地说:除非你确定你有一个存储库的完整副本安全地存储在Heroku之外的地方，否则不要这样做。重置操作将删除存储库内容。

重置:

如果您还没有安装Heroku工具带(其中包含命令行客户端)。 如果你还没有安装heroku-repo插件。 Heroku插件:安装https://github.com/heroku/heroku-repo.git 执行重置，删除存储库并创建一个新的空存储库 heroku回购:重置 像往常一样按下Heroku遥控器;它会重新加载所有内容。

使用Git，两个常规(非裸)存储库不能直接来回推/拉文件。必须有一个中间裸存储库。显然，这有点像一对已婚夫妇有了一个孩子，但这对夫妇要离婚了。父母之间不会相互交谈，但他们会通过孩子进行交流。

因此，您有一个存储库，您将这个存储库克隆到一个裸存储库，然后将其克隆到第三个。第一个和第三个可以通过第二个存储库(裸存储库)交换信息。我想这是有道理的，因为你不希望别人在未经你同意的情况下将东西签入你的存储库，因为这可能会导致合并冲突等。

这里有一个例子:

在PC上，在~/workspace

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

在笔记本电脑上，在~/workspace中(不要init git等)

git clone //LJZ-DELLPC/remote-repository.git/ .

//然后进行各种提交，并推送它们:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push    

然后回到PC，在~/workspace中

git pull

//然后进行各种提交，并推送它们:

git push

在笔记本电脑 git拉

等等。

下面是一台机器上的一个绝对具体的例子，直接从命令窗口复制，这样我们就知道没有遗漏任何步骤，它确实可以工作，等等:

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

旧版本的Git允许推入当前签出的非裸库分支。

事实证明，这是一件非常令人困惑的事情。所以他们添加了你看到的警告信息，这也是非常令人困惑的。

如果第一个存储库只是充当服务器，那么按照其他答案的建议将其转换为裸存储库，然后就可以完成了。

然而，如果你需要在两个都在使用的回购之间有一个共享分支，你可以通过下面的设置来实现

Repo1 -将充当服务器，也用于开发

Repo2—仅用于开发

按如下方式安装Repo1

创建一个分支来共享工作。

git branch shared_branch

为了安全起见，您还应该创建一个$(REPO)。Git /hooks/update拒绝对shared_branch以外的任何内容的任何更改，因为你不想让别人乱动你的私有分支。

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

现在在repo1中创建一个本地分支，您将在其中执行实际工作。

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

(可能需要git配置——global push.default upstream，以便git push工作)

现在您可以使用

git clone path/to/repo1 repo2 
git checkout shared_branch 

此时，您已经设置了repo1和repo2，以便在本地分支上工作，从repo1中的shared_branch中进行推和拉操作，而无需担心错误消息或repo1中的工作目录不同步。您使用的任何正常工作流都应该工作。

git配置——local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

在服务器存储库上使用它，如果没有发生未跟踪的覆盖，它也会更新工作树。

正如VonC在评论中提到的，它是在Git 2.3中添加的。

我已经编译了Git 2.3并尝试了一下。示例用法:

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

耶，b被推了!

以防有人觉得有用。对我来说，这是一个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拉;git推 推入不同分支: Git push origin master:foo 并在远程合并它(通过git或pull-request) Git合并foo 强制执行(不推荐，除非你故意通过rebase改变提交): Git push origin master -f 如果仍然被拒绝，禁用远程存储库上的denyCurrentBranch: git config receive.denyCurrentBranch ignore

你可能做了什么导致了这个:

当你去开发一个小程序时，这种事情就会发生。你要改变一些已经生效的东西，所以你施放了三级永久撤销法术:

machine1:~/proj1> git init

然后开始添加/提交。但随后，项目开始变得更加复杂，你想从另一台计算机(比如你的家用PC或笔记本电脑)上处理它，所以你做了这样的事情

machine2:~> git clone ssh://machine1/~/proj1

它会复制，一切看起来都很好，所以你可以从machine2上处理代码。

然后……您尝试从machine2推送提交，并在标题中得到警告消息。

The reason for this message is because the git repo you pulled from was kinda intended to be used just for that folder on machine1. You can clone from it just fine, but pushing can cause problems. The "proper" way to be managing the code in two different locations is with a "bare" repo, like has been suggested. A bare repo isn't designed to have any work being done in it, it is meant to coordinate the commits from multiple sources. This is why the top-rated answer suggests deleting all files/folders other than the .git folder after you git config --bool core.bare true.

Clarifying the top-rated answer: Many of the comments to that answer say something like "I didn't delete the non-.git files from the machine1 and I was still able to commit from machine2". That's right. However, those other files are completely "divorced" from the git repo, now. Go try git status in there and you should see something like "fatal: This operation must be run in a work tree". So, the suggestion to delete the files isn't so that the commit from machine2 will work; it's so that you don't get confused and think that git is still tracking those files. But, deleting the files is a problem if you still want to work on the files on machine1, isn't it?

那么，你到底应该怎么做呢?

这取决于你还打算在machine1和machine2上工作多少…

如果你已经完成了从machine1开始的开发，并将所有的开发都转移到machine2上……只需要做排名最高的答案所建议的:git config——bool core。完全正确，然后，可选地删除该文件夹中除.git之外的所有文件/文件夹，因为它们无法跟踪，可能会引起混乱。

如果你在machine2上的工作只是一次性的，你不需要在那里继续开发……那就别费事去做单纯的回购了;只是ftp / rsync / scp /等。你从机器*2*上的文件放到机器*1*上的文件上面，从机器*1*上提交/推送，然后删除机器*2*上的文件。其他人建议创建一个分支，但我认为如果您只是想合并从另一台机器上一次性完成的一些开发，那么这有点混乱。

如果你需要在machine1和machine2上继续开发……然后你需要正确地设置。您需要将您的repo转换为bare，然后您需要在machine1上创建一个副本，以便您在其中工作。可能最快的方法就是去做

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

非常重要:因为您已经将回购的位置从proj1移动到proj1。Git，您需要在machine2上的. Git /配置文件中更新它。之后，您可以从machine2提交更改。最后，我试着把我的裸回购放在一个中心位置，远离我的工作树(也就是说，不要把“proj1。Git '和'proj1'在同一个父文件夹中)。我建议您也这样做，但我想让上面的步骤尽可能简单。

检查目标项目中的.git/config:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

如果核心。Bare为false，你可以设置为true:

$ git config core.bare true

然后在本地推送到远程:

git push remote_repo   // suppose the destination repo is remote_repo

它会成功，在remote_repo你可以检查git版本。

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

现在你不能在你的“工作区”中使用git了:

$ git status
fatal: This operation must be run in a work tree

你应该裸露。裸背为假。

$ git config core.bare false

使用这个将它推到远程上游分支为我解决了这个问题:

git push <remote> master:origin/master

远程无法访问上游回购，因此这是将最新更改导入远程的好方法

当我在NAS上克隆了一个回购，然后将该回购克隆到我的机器上时，我遇到了这个问题。

设置是这样的:

原始(github):

克隆到我的私人家庭网络中的网络存储(我的家庭网络) 签出的分支:DEVELOPMENT 克隆到其他机器(笔记本电脑、我办公室的小型数据中心服务器等) 签出的分支:DEVELOPMENT

当我试图从笔记本电脑提交到NAS服务器时，出现的错误是

! [remote rejected]   development -> development (branch is currently checked out)

根本原因是在NAS服务器上签出了DEVELOPMENT分支。我的解决方案是在NAS存储库上切换到任何其他分支。这让我可以提交我的更改。

让我加上我的50美分，因为投票最多的答案https://stackoverflow.com/a/3251126/3455918建议将远程repw转换为裸库，如果这不是我想要的呢?

最后，我必须在远程机器上有相同的代码，但不只是.git边缘的某个地方的一团字节。

第二次投票(在撰写本文时)的解决方案https://stackoverflow.com/a/2933656/3455918可以完成这项工作，但在测试之后，我最终不得不不断地在远程机器上的分支之间切换，以“释放”我想从本地机器推送到的分支。

这招对我很管用:

到目前为止对我有效的另一个解决方案不是我的，功劳是给了一个对第一个解决方案发表评论的用户@kxr。

在远程机器上，您必须在repo目录中执行此命令。

git配置receive.denyCurrentBranch updateInstead

在此之后，您就完成了!

显然，这种解决方案可能有一些缺点，但对于将本地机器代码同步到远程回购的简单任务来说，它可能已经足够好了。

如果有人在评论中解释为什么在github上创建一个全新的repo，将你的本地文件夹链接到它，并开始做git push origin master而没有错误，我会很感激。

但是尝试在远程服务器上进行同样的回购会产生错误:

！ [远程拒绝]master -> master(分支当前签出)