是否可以通过高级访问控制来实现GIT工作流程？

Question

I am in progress of searching efficient way to use GIT work-flow with advanced access permissions. The work flow is this: http://nvie.com/posts/a-successful-git-branching-model/ but simpler alternative can be taken in order to understand the actual requirement which is described in the next paragraph.

What seems I need is to configure each developer with file/directory permissions (may not include "list" permission but only read and write if no "read" permission means that the DEV will not see the file/directory at all). That way I will be able to share enough but limited part of software with a developer. The second important thing is that he should still be able to send pull requests for merge but only with the source addition and/or modification in the allowed directories/files.

To aggregate the question: is there any way to use given GIT Workflow with the ability to share partially the repository and still use the full potential of GIT repository. Git modules and subtree is not efficient and seems for another use-cases because they will sacrifice the repository power.

Answer 1

There is no support for directory-level permissions in git. Access is generally controlled by something outside git (filesystem ACLs, web server authentication, permissions managed by GitHub, GitLab, TFS, Bitbucket, ...) but even at that, a commit is a more or less atomic unit and I've never heard of any git host that will try to provide access control within a commit.

If you want different users to have access to different parts of the project, the only solution I can think of is to use multiple repos.

If you can divide that along directory lines, you might be able to set something up with subtrees or submodules so that you can have your "full access" repo pull everything together automatically. That won't be seamless, but you can probably make something work.

If that kind of division isn't feasible, then the problem is much bigger. In this scenario, Version X of the full project is necessarily a separate commit vs. Version X of the subset of files available to the developer. Your "full access" repo can keep both sets of commits, but syncing changes between the two is still a very significant exercise.

You can impose whatever kind of controls you want on pushes back into your repository (using hooks); but if the rule is that the developer can't see or even be aware of some files, it's simply not something you'll do easily with git.