如何在 git 存储库上正确使用组文件权限？

How to use group file permissions correctly on a git repository?

提问by rich

We're accessing a shared git repository via file paths, for various reasons I'll omit for now, created with --shared=group.

我们正在通过文件路径访问共享的 git 存储库，出于各种原因，我现在将省略，使用 --shared=group 创建。

We have various unix groups but all share a common group. If I run a chgrp -R on the git repository everyone can read from it, but if someone writes to it more often than not new files are created which do not use the common group.

我们有各种 unix 组，但都共享一个公共组。如果我在 git 存储库上运行 chgrp -R ，每个人都可以从中读取，但是如果有人更频繁地写入它，则会创建不使用公共组的新文件。

This problem appears to be because our primary group is not the shared one and if we run a newgrp all seems to work well.

这个问题似乎是因为我们的主要组不是共享组，如果我们运行 newgrp 似乎一切正常。

There are issues with this approach though; newgrp is slow and it spawns a new shell, which makes me think calling it in a .bash_profile would be a bad idea, without even considering whether or not we'd want allour new files to use the common group. Relying on memory to run it before doing any git work seems like a recipe for disaster too though.

但是这种方法存在问题；newgrp 很慢，它会产生一个新的 shell，这让我觉得在 .bash_profile 中调用它是一个坏主意，甚至没有考虑我们是否希望所有新文件都使用公共组。不过，在做任何 git 工作之前依靠内存来运行它似乎也是一种灾难。

So... any suggestions?

所以……有什么建议吗？

采纳答案by Wes Hardaker

You need to set the setgid biton the group as well.

您还需要在组上设置setgid 位。

chgrp -R GROUP /path/to/repo
find /path/to/repo -type d -print0 | xargs -0 chmod g+s 

回答by fikovnik

An existing repository that has not been created with --sharedcan be turned shared using following commands:

--shared可以使用以下命令将尚未创建的现有存储库变为共享：

# make the repository shared
git config core.sharedRepository group # or whatever other sharing option
# fix the setgid bit
find . -type d | xargs chmod g+s
# repair the permissions
chmod -R g+r *

回答by Arrowmaster

Is this a bare repo? If its a bare repo and you used --shared when you created it then this shouldn't be happening which is why I'm asking.

这是一个裸回购吗？如果它是一个裸仓库并且您在创建它时使用了 --shared 那么这不应该发生，这就是我问的原因。

If it is a bare repo maybe some of the directories got changed to g-s, if that happened you need to either chmod g+xall the directories only, make sure you don't do it to any files. An easier way than that might be to just git init --bare --shared=groupa new repo and push the content back to it from somebodies clone.

如果它是一个裸仓库，则可能某些目录已更改为 gs，如果发生这种情况，您只需要访问chmod g+x所有目录，请确保不要对任何文件执行此操作。比这更简单的方法可能是创建git init --bare --shared=group一个新的存储库并将内容从某人的克隆中推送回它。

回答by chovy

I had to use a combination from the above answers:

我不得不使用上述答案的组合：

git config core.sharedRepository group
chgrp -R GROUP /path/to/repo
find /path/to/repo -type d -exec chmod g+rwxs {} \;

回答by ggll

Once the bare repository has the shared=groupflag, git will take care of the rest, so the following has to be done only once. Also setgidis deprecated for this use. Here I copy/paste my answer from serverfault:

一旦裸仓库有了shared=group标志，git 就会处理剩下的事情，所以下面的事情只需要做一次。也setgid不赞成这种用途。在这里，我从 serverfault复制/粘贴我的答案：

Assuming repogroupis your group, and you have cdto the repo directory:

假设repogroup是你的组，你必须cd到 repo 目录：

First change the shared flag to group:

首先将共享标志更改为group：

git config core.sharedRepository group 

Note: here you must use the keyword group, not the group name. This is equivalent to creating the bare repository with option --shared=group.

注意：这里必须使用关键字group，而不是组名。这相当于使用选项创建裸存储库--shared=group。

Then change the group for the whole repository:

然后更改整个存储库的组：

chgrp -R repogroup .

To make sure that existing directories are group-writable (g+w), and existing executables also become group-executables (g+X) you also need to:

为了确保现有目录是组可写的 ( g+w)，并且现有的可执行文件也成为组可执行文件 ( g+X)，您还需要：

chmod -R g+wX .

Once you have done this, git will honor the shared=groupflag and take care of group permissions in the following, both for existing and new files, so you'll never need again to umaskor chgrp.

完成此操作后，git 将遵守该shared=group标志并处理以下组权限，包括现有文件和新文件，因此您将不再需要umask或chgrp。

I'll put the source in a comment if I find it back.

如果我找到它，我会将来源放在评论中。