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

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

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版本在分支签出时拒绝通过推送更新该分支。

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

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

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

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

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

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

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

重置:

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

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

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

git push <remote> master:origin/master

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

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

在远程服务器上:

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

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

git push origin master:master