ric*_*ich 25 unix git permissions file-permissions
我们通过文件路径访问共享git存储库,由于各种原因我现在将省略,使用--shared = group创建.
我们有各种unix组,但都有一个共同的组.如果我在git存储库上运行chgrp -R,每个人都可以从中读取,但是如果有人写入它,则通常会创建不使用公共组的新文件.
这个问题似乎是因为我们的主要组不是共享组,如果我们运行newgrp,似乎一切都运行良好.
但是这种方法存在问题; newgrp很慢,它产生了一个新shell,这让我觉得在.bash_profile中调用它会是一个坏主意,甚至不考虑我们是否希望我们所有的新文件都使用公共组.在做任何git工作之前依靠内存来运行它似乎也是灾难的一个秘诀.
那么......有什么建议吗？
Wes*_*ker 22
您还需要在组上设置setgid位.
chgrp -R GROUP /path/to/repo find /path/to/repo -type d -print0 | xargs -0 chmod g+s
fik*_*nik 22
--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 *
这是一个简单的回购？如果它是一个裸露的回购并且您在创建时使用了--shared那么这应该不会发生,这就是我要问的原因.
如果它是一个裸仓库,也许某些目录已更改为gs,如果发生这种情况,您只需要chmod g+x所有目录,请确保不对任何文件执行此操作.比这更简单的方法可能只是git init --bare --shared=group一个新的repo并从somebodies clone将内容推回给它.
我不得不使用以上答案的组合:
git config core.sharedRepository group
chgrp -R GROUP /path/to/repo
find /path/to/repo -type d -exec chmod g+rwxs {} \;
一旦裸仓库有了shared=group标志，git 就会处理剩下的事情，所以下面的事情只需要做一次。也setgid不赞成这种用途。在这里，我从 serverfault复制/粘贴我的答案：
假设repogroup是你的组，你必须cd到 repo 目录：
首先将共享标志更改为group：
git config core.sharedRepository group
注意：这里必须使用关键字group，而不是组名。这相当于使用选项创建裸存储库--shared=group。
然后更改整个存储库的组：
chgrp -R repogroup .
为了确保现有目录是组可写的 ( g+w)，并且现有的可执行文件也成为组可执行文件 ( g+X)，您还需要：
chmod -R g+wX .
完成此操作后，git 将遵守该shared=group标志并处理以下组权限，包括现有文件和新文件，因此您将不再需要umask或chgrp。
如果我找到它，我会将来源放在评论中。