维修权限

确定并修复根本原因后（见下文），您需要修复权限：

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 .

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

根本原因

该错误可能由以下原因之一引起：

• 存储库未配置为共享存储库（参见 参考资料core.sharedRepository）git help config。如果输出：

   git config core.sharedRepository
  

is not groupor trueor or 1or some mask,尝试运行：

     git config core.sharedRepository group

然后重新运行递归chmod和chgrp（参见上面的“修复权限”）。

• 操作系统不会将目录上的 setgid 位解释为“所有新文件和子目录都应继承组所有者”。

当core.sharedRepository是true或group时，Git 依赖 GNU 操作系统（例如，每个 Linux
发行版）的特性来确保新创建的子目录归正确的组（所有存储库用户所在的组）所有。此功能记录在GNU coreutils
文档中：

… [如果] 设置了目录的 set-group-ID 位，则新创建的子文件继承与目录相同的组，新创建的子目录继承父目录的 set-group-ID
位。… [此机制让] 用户通过减少使用chmod或chown共享新文件的需要更轻松地共享文件。

然而，并不是所有的操作系​​统都有这个特性（NetBSD 就是一个例子）。对于这些操作系统，您应该确保所有 Git
用户都具有相同的默认组。或者，您可以通过运行使存储库在世界范围内可写git config core.sharedRepository world（但要小心——他的安全性较低）。

• 文件系统不支持 setgid 位（例如，FAT）。ext2、ext3、ext4 都支持 setgid 位。据我所知，不支持 setgid 位的文件系统也不支持组所有权的概念，因此所有文件和目录无论如何都将归同一个组所有（哪个组是挂载选项）。在这种情况下，请确保所有 Git 用户都在拥有文件系统中所有文件的组中。

• 并非所有 Git 用户都在拥有存储库目录的同一组中。确保目录上的组所有者正确并且所有用户都在该组中。