Git - 多个用户使用相同的工作目录：.git 元文件中的权限问题

问题：当多个用户有权访问同一工作目录时，元数据中可能会出现权限问题（如果有）git执行操作。

免责声明：在你责备我之前 - 我意识到共享工作目录与 Git 所代表的含义背道而驰，而且我不是在谈论在此共享目录中执行除只读操作之外的任何操作 - 我们在自己的本地存储库中完成所有工作。

我愿意接受关于另一种方法来完成我们正在尝试做的事情的建议，因为我们的方法当然不是最佳实践，但我不确定这种对话对其他人来说是否有用。现在让我提供一些有关我们这样做的原因的详细信息：

我们的团队中有几位构建大师。我们部署到 Linux 服务器，并使用直接从 Git 提取的构建脚本进行构建。我们目前无法使用 CI（例如 Jenkins/cruisecontrol），因此我们有一个存储库，我们可以从中签出并进行 QA 构建。

我们在脚本中执行一些 git 操作。这包括一些提交标记（内容被标记为 QA-current、QA-previous 等）。所以我想我们实际上并不完全是只读的。由于构建脚本的性质，我们运行它sudo'ed 作为普通用户（我们将该用户称为 DevAdmin）。我意识到这可能是一种不好的做法，并且可能是痛苦的根源，因为它迫使我们使用共享回购结账。

如果我们在那个工作目录中总是被 sudo 的话，这一切都很好。问题是，有时，我们中的一个人会做一件事git pull或意外类似的东西，而无需被 sudo 为 DevAdmin。所以大部分文件在.git属于 DevAdmin（执行初始克隆），但每当我们这样做时，我们最终都会得到目录.git/objects包含特定用户拥有的文件。这些被创建为组不可写。我也注意到了ORIG_HEAD例如，所有权错误。因此，当我们尝试以开发管理员身份执行某些操作时，我们会遇到问题。

我们可以做些什么来解决这个问题吗？现在，我们必须认识到它已经发生，然后让服务器管理员来处理chown .git回到开发管理员。或者让用户删除有问题的元文件，或者至少chmod将它们设置为组可写。这一切看起来都很糟糕。

我考虑了几个不涉及显着改变我们的构建和维护流程的选项：

如果我们删除组写访问权限.git并将其限制为 DevAdmin，这会阻止这种情况再次发生吗？这似乎是最直接的选择。

或者有没有办法让一切都在.git 组可写，即使它是新创建的？这看起来像是自找麻烦。

我还缺少其他明显的东西吗？我意识到最好的事情可能是改变我们的流程，以便用户可以在自己的存储库中工作，但在业务环境中，存储库可能会变得非常大（罐子尚未分离出来，大量二进制文件等...)，而且我们无法为每个人的帐户提供多 GB 的存储库。此外，我们的系统管理员需要做大量的工作来改变他们的流程以实现这一点。

任何想法表示赞赏。

有一个方式数量 https://serverfault.com/questions/26954/how-do-i-share-a-git-repository-with-multiple-users-on-a-machine来解决这个问题。就我个人而言，我建议在您现有的存储库中使用以下内容：

# Create a group named "gitshare" that will share the repository.
sudo groupadd gitshare

# Add yourself and as many others as you want to the group.
sudo adduser "$LOGNAME" gitshare

# Everything else needs to run from the top level of your Git repository.
cd /path/to/repository

# Add group permissions for *new* modifications to repository.
git init --shared=group

# Fix permissions for existing repository objects.
chown -R :gitshare "$PWD"
chmod -R g+swX "$PWD" 

显然，您需要确保用户具有一直到您的存储库的目录遍历权限（例如，用户私有目录可能会导致问题），并且所有需要访问权限的团队成员都属于存储库的共享组。不过，经过初始设置后，它应该“正常工作”。