问题
For example: I have a repository - repo1 with such fs hierarchy
repo1:
js
html
php/core
php/menu
And I want to give to repo1:php/menu, RW permission - to a freelancer, but for all repo1 - this freelancer must have only Read-Only permission.
Can I do this with gitolite or gitosis or may be something else?
回答1:
The repo access rights on a DVCS is always linked to the all repo, not part of if, mainly because you clone all of it (shallow clone is hard).
That means gitolite (I won't even mention gitosis which is obsolete) can establish restrictions on:
- accessing a all repo
- writing only certain branches (but you cannot limit read access to certain branch)
But it cannot prevent a user to access parts of a repo.
However, since gitolite v3 or 'g3' (April 17th, 2012), you can, with VREF rules, prevent writing (pushing to) certain directories (in addition of certain branches).
Original answer (gitolite V2 or 'g2', November 2011)
See gitolite.conf -- by example and side note: "R" permissions for refs
repo gitolite-admin
RW+ = sitaram
# this is equivalent to:
RW+ refs/.* = sitaram
Sitaram is the only admin. He can push, create, delete, or rewind any branch or tag in the gitolite-admin repo.
R master = wally # MEANINGLESS! WILL NOT DO WHAT YOU THINK IT DOES!
This won't work.
You can only restrict "read" access at the repo level, not at the branch level.
This is a git issue, not a gitolite issue. Go bother them, or switch to gerrit.
回答2:
What you want to do seems possible with gitolite. Look at this: http://sitaramc.github.com/gitolite/bac.html
Read access will be at repo level only, however but thats what you want anyways..
回答3:
First issue is what does it mean "read-only" and "read-write" in context of git. A "write" in git consists of two separate operations. The "commit", which creates a revision spanning whole tree (git does not have any per-file history at all) and a "push" that copies that revision into your central repository.
There is no way to limit the "commit" for anybody but yourself, since user must install any hooks into their working repository manually. So the user in question will be able to create a commit modifying anything at all. They will also be able to share that commit with other members of your team by sending patch, bundle or allowing them to pull from the work repository directly.
What you can limit is the "push" to the central repository. You can create an update or pre-receive hook (they only differ in calling convention) that will check content of the revisions and reject them if they touch something you don't want. The update hook receives 3 arguments, branch name, old commit and new commit, so you would just git diff --name-status the old and new commit and if given user (you'll have to look up how to get that from gitolite) is doing the push and the changes affect other than the subdirectory you allow, reject the push.
The user will still be able to author a revision that affects other parts of the tree and get it into the trunk by having somebody else push it. It might be useful, but your colleagues need to be aware that they should review changes they pull from the consultant directly.
Note, that checking commit authors or committers is not secure, because the author can be set freely.
来源：https://stackoverflow.com/questions/8047416/gitolite-or-gitosis-permission-on-directory-inside-of-the-repository