17

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

免责声明：在你责备我之前——我意识到共享一个工作目录与 Git 所代表的背道而驰，而且我不是在谈论在这个共享目录中做除了只读操作之外的任何事情——我们在我们自己的本地存储库中完成所有工作.

我愿意接受有关另一种方法来做我们正在尝试做的事情的建议，因为我们的方法肯定不是最佳实践，但我不确定这种对话是否对其他人有用。所以现在让我提供一些关于我们为什么这样做的细节：

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

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

这一切都很好，如果我们在那个工作目录中总是被 sudo'ed。问题是，有时，我们中的一个人会git pull意外地做一个或类似的事情，而不会被 sudo'ed 为 DevAdmin。因此，其中的大多数文件.git都归 DevAdmin（执行初始克隆）所有，但每当我们这样做时，我们最终.git/objects都会得到包含特定用户拥有的文件的 dir。这些被创建为组不可写。例如，我还注意到ORIG_HEAD所有权错误。因此，当我们尝试作为 DevAdmin 做某事时，我们会遇到问题。

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

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

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

或者有没有办法让.git 组中的所有内容都是可写的，即使它是新创建的？这似乎是从麻烦中问出来的。

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

任何想法表示赞赏。

4

3 回答 3

30

有很多方法可以解决这个问题。就个人而言，我会在您现有的存储库中推荐以下内容：

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

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

于 2012-06-25T23:38:59.513 回答
2

我刚遇到这个问题，花了几个小时才找到解决方案，因为它是如此简单。我几乎尝试了我在 CodeGnome 提供的另一个链接上看到的所有内容。

我正在使用 Centos 6.x，解决方案是更改用户的 umask……这要求我们对每个帐户都这样做……我们只有 2 个在同一个目录上工作。没那么痛。

对我有用的解决方案是这个，无需更改服务器的配置： http ://www.avajava.com/tutorials/lessons/how-do-i-set-the-default-file-and-directory-权限.html

如果 /home/user 目录中不存在 .bashrc 文件，就像我的情况一样，您只需从骨架中复制 /ect/skel 中的文件，然后在添加后将其复制到您的主（用户）目录在文件末尾：

umask 002

这为用户提供了组中其他人创建的新文件夹的 chmod 775。当然，一旦这个项目完成，不再是在测试环境中，我们将默认设置回 chmod 755 (umask 022)。这不仅给了 Git 覆盖的权限，而且还可以写入上传到 sFTP 上的文件，而不会出现权限被拒绝的问题。.

于 2016-09-21T05:02:58.453 回答
0

9 年后，当我在 Google 上搜索时，我来到了这里，我想我为我的特定用例想出了一个新颖的解决方案。

解决方案：在远程仓库中，我们创建了一个钩子，该钩子将授予该组的写入和执行权限。钩子位于远程 repo 的目录中，在该hooks目录下并命名post-receive（没有文件扩展名；我们必须手动创建文件并具有执行权限）。我们将它创建为一个bash看起来像这样的脚本：

#!/bin/sh
chmod -R g+rwx /path/to/remote/repo

所有涉及的用户都属于同一组，并且 git 挂钩以执行推送的用户身份运行。因此，该用户基本上更改了他们有权访问的文件，从而允许组中的其他任何人都可以访问。

情况：在工作中，我们有一个包含数十年程序的文件夹，这些程序会定期更新和调整。我们想要版本控制，所以我们设置了一个遥控器（尽管在同一台机器上），我们git init编辑了有问题的文件夹并将其指向遥控器。我们中更喜欢冒险的人希望将 repo 克隆到我们的笔记本电脑并在那里处理代码库，然后推送更改，但我们希望不那么冒险的人不必获取/拉取。repo 与原始代码库位于同一台机器上，因此我们制作了一个 git 钩子，它会自动传播更改。

服务器所有者对权限非常严格，导致我们的（共享）组不会自动获得写入权限的 umask 策略。我们也不是 sudoers，所以我们不能强迫它工作（可以这么说）。

“陷阱”：

  • 如果您已经处于由于文件权限而无法推送的情况，请让每个用户授予权限 ( chmod -R g+rwx /path/to/remote/repo)。他们会因为他们无权访问的文件而收到错误，但这很好。一旦每个人都这样做了，你应该很高兴:)
  • 这与 OP 无关，但在我们的情况下，我们在本地克隆中使用了 fetch+pull 钩子，然后还更新了对克隆.git目录内容的权限。我们最初忘记了最后一部分：|

免责声明：我不是这方面的专家——安全、Linux 或 git。我知道足以让它在我所拥有的范围内工作，但我确信有更好的方法。

希望这对其他人有所帮助，如果我有任何术语错误，请原谅！

于 2021-10-19T20:04:56.763 回答