Git - 多个用户使用相同的工作目录 : permissions issues in . git 元文件

Question

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

免责声明:在你惩罚我之前 - 我意识到共享工作目录与 Git 所代表的东西背道而驰，我不是在谈论做除了只读操作之外的任何事情共享目录 - 我们在自己的本地存储库中完成所有工作。

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

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

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

如果我们在那个工作目录中总是被 sudo'ed，那么一切都会好起来的。问题是，有时我们中的一个人会不小心执行 git pull 或类似的操作，而没有被作为 DevAdmin sudo。所以 .git 中的大部分文件都归 DevAdmin(执行初始克隆的人)所有，但每当我们这样做时，我们最终会在 .git/objects 中找到目录包含特定用户拥有的文件。这些被创建为组不可写。例如，我还注意到 ORIG_HEAD 的所有权不正确。因此，当我们尝试以 DevAdmin 的身份做某事时，我们会遇到问题。

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

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

如果我们删除 .git 上的组写入权限并将其限制为 DevAdmin，是否可以防止这种情况再次发生？这似乎是最直接的选择。

或者是否有办法使 .git 中的所有内容都可组写入，即使是新创建的？这似乎是在自找麻烦。

我还缺少其他明显的东西吗？我意识到最好的办法可能是改变我们的流程，以便用户可以在他们自己的 repo 中工作，但在商业环境中， repo 可能会变得非常大( jar 还没有分开，很多二进制文件等...)，而且我们不能为每个人的帐户提供多 GB 的 repo 。此外，我们的系统管理员在改变他们的流程以允许它之前还有很多工作要做。

如有任何想法，我们将不胜感激。

Answer 1

有一个number of ways来解决这个问题。就个人而言，我会在您现有的存储库中推荐以下内容:

# 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" 

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