调试这种情况的一个好方法是，下次发生这种情况时，SSH到远程repo, cd到objects文件夹，并执行ls -al。

如果您看到2-3个文件具有不同的用户:组所有权，那么这就是问题所在。

在过去，我遇到过一些遗留脚本访问我们的git repo，通常意味着不同的(unix)用户最后推送/修改文件，而您的用户没有权限覆盖这些文件。你应该创建一个共享git组，所有启用git的用户都在其中，然后递归地chgrp objects文件夹和它的内容，这样它的组所有权就是共享git组。

您还应该在文件夹上添加一个sticky位，以便在文件夹中创建的所有文件将始终具有git组。

Chmod g+s目录名

更新:我不知道core. sharerepository。很高兴知道这一点，尽管它可能只是做上述工作。

sudo chmod -R ug+w .;

基本上，.git/objects文件没有写权限。上面的代码行授予目录中所有文件和文件夹的权限。

如果您使用不同的用户运行git init，而不是您计划在推送更改时使用的用户，则很容易发生这种情况。

如果你盲目地遵循[1]上的说明，这可能会发生，因为你可能创建了git-user作为根用户，然后立即转移到git init，而没有改变用户。

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

对我来说，这些建议都没用。我在Windows上，这对我来说很有效:

将远程回购复制到另一个文件夹中 共享文件夹并授予适当的权限。 确保您可以从本地计算机访问该文件夹。 将此回购添加为本地回购中的另一个远程回购。(git remote add foo //SERVERNAME/path/to/ replicated /git) Push到foo。Git push foo master。有用吗?太棒了!现在删除not-working repo并将其重命名为之前的任何内容。确保权限和共享属性保持不变。

我在使用Vagrant运行远程开发开发机器时得到了这个错误。上述解决方案都不能工作，因为所有文件都具有正确的权限。

我把config.vm.box = "hasicorp/ bioniic64 "改为config.vm.box = "bento/ubuntu-20.10"。

修复权限

在你确定并修复了潜在的原因(见下文)后，你会想要修复权限:

cd /path/to/repo/.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

注意，如果你想让每个人都能修改存储库，你不需要chgrp，你需要将chmod更改为sudo chmod -R a+rwX。

如果您不修复根本原因，错误将不断出现，您将不得不一遍又一遍地重新运行上述命令。

根本原因

该错误可能是由以下原因之一引起的:

The repository isn't configured to be a shared repository (see core.sharedRepository in git help config). If the output of: git config core.sharedRepository is not group or true or 1 or some mask, try running: git config core.sharedRepository group and then re-run the recursive chmod and chgrp (see "Repair Permissions" above). The operating system doesn't interpret a setgid bit on directories as "all new files and subdirectories should inherit the group owner". When core.sharedRepository is true or group, Git relies on a feature of GNU operating systems (e.g., every Linux distribution) to ensure that newly created subdirectories are owned by the correct group (the group that all of the repository's users are in). This feature is documented in the GNU coreutils documentation: ... [If] a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. ... [This mechanism lets] users share files more easily, by lessening the need to use chmod or chown to share new files. However, not all operating systems have this feature (NetBSD is one example). For those operating systems, you should make sure that all of your Git users have the same default group. Alternatively, you can make the repository world-writable by running git config core.sharedRepository world (but be careful—this is less secure). The file system doesn't support the setgid bit (e.g., FAT). ext2, ext3, ext4 all support the setgid bit. As far as I know, the file systems that don't support the setgid bit also don't support the concept of group ownership so all files and directories will be owned by the same group anyway (which group is a mount option). In this case, make sure all Git users are in the group that owns all the files in the file system. Not all of the Git users are in the same group that owns the repository directories. Make sure the group owner on the directories is correct and that all users are in that group.