Question about Git and Users

Question

I want to use Git in a project but only some developers can Access in some folders (not all folders of the Project). Can Git limits the access to folders to users? How?

An example:
Project p_example
/scripts
/src
/docs
Users: A, B and C

Only B and C can access into scripts, src and docs folders but A only can access into scripts folder.

Answer 1

Git, in and of itself, cannot limit access to _anything_. It is not an access control system.

In order to limit access to one or more directories (folders) or files, you must use the facilities with the host operating system. Because you said "folder" instead of "directory", I assume that you are running Windows. I dont _do_ Windows . On a real OS, like UNIX or Linux, you can use Access Control Lists (ACLs) to enforce limits on a users abilities. I would hope that Windows has something similar.

But how you do this when "the git way" is for every user to have their own complete copy of the entire repository exist on their personal computer, is really beyond me. Normally there is a bare repository on a "server". The developer does a "git clone" on it. This downloads everything in the repository and creates the working directory. The files and folders all belong to that user. The "server" is no longer in the picture at all. The developer can do what [s]he wants. They may, or may not, be able to do a "git push" to merge their changes back to the bare repository from which they did the "git clone". But, if they can, that operation is an "all or nothing". There is nothing within git, as distributed, to say that developer "x" can do a push, but only for files in directory "y". You might be able to do something like this by using a "Server Side Hook" as in:
http://git-scm.com/book/en/Customizing-Git-Git-Hooks

If the above is what you want, then you might want to look at installing gitolite on your server. It wont address the fact that a developer will get the entire repository contents. But it can control what they can successfully "push" to the bare repository.
https://github.com/sitaramc/gitolite

Centralized SCM systems, such as Subversion, can control who can "check out" what. But git does not take this approach.

Answer 2

Impossible with Git. And you have a mindset not matching that of required to use Git sensbibly.

First, note that you're talking about some sort of central repository without even mentioning that fact. But Git is not a centralized system -- quite contrary, it's a distributed system where each developer has its *own* repository and has total control over its contents. I mean, whatever imaginary restrictions you would like to
set up (we'll return to them shortly), they have no meaning at all in the repositories in which actual developers do their actual work.

Second, Git does not track directories. This might sound weird (to someone coming from, say, subversion) but it's true nevertheless --
the fact Git knows something about directories does not imply it actually pays any attention to them; Git indeed has the concept of "trees", which resembles directories, in its repository format, but this is just a byproduct of the fact filesystems on popular OSes Git runs on are also hierarchical. When you rename a file or directory in a Git repository, and commit this change, no information is recorded to explicitly mention this fact; to give you an example, the git mv command which "renames" a file (possibly across directories) is just a shortcut for "delete and untrack the file then move it physically in the work tree then start tracking it at its new location".

Now let's get back to your centralized workflow. I infer from your question that you have one central ("master", "blessed", "reference" or whatever) repository everyone clones from and pushes to, and you want fine-grained control over who pushes what. Now, since Git supports so-called "hooks" -- scripts which run at key moments of the repository updates, including pushes -- you're in theory are able to write a post-receive hook which would traverse over each of the updated "refs" (branches, tags etc), then for each ref traverse the new line of commits that ref points to, and inspect it to see if the commit touches any paths you want / do not want, and fail the hook, if needed, to make the whole operation abort. You can see that this is doable but hard to get right.

Now let's try to reconsider your approach to this problem. "The Git way" in a case like this is just to not let every single developer to commit to that reference repo. Instead, have one or two designated "integrators" who will be responsible for taking changes from individual developers, *verify these changes* and, if they are okay, integrate them and push the resulting commit(s) to the main repo. If needed, your individual developers might have their own "central" repositories, serving as backups of their local ones and/or for means of easier visibility of the stuff those developers are working on. Or each developer might have their personal set of branches in the single central repository.

The de-facto standard tool to implement per-repository and per-branch read/write (or more fine-grained) access for the case of accessing the server via SSH with virtual Git users is gitolite [1]. This tool also
makes possible to have per-developer repositories (it calls them "wild" repositories").

The proposed workflow is like this:

• Each individual developer either

• Has their local repo accessible directly from their workstation (it's not hard to implement, really, -- one should stop thinking that VCS requires a server to operate) or

  • Has their personal central mirror for their local repository.
  • has their personal set of branches in the single central repository.

  In either case each developer either works in their local repo, and integrators pull from it, or they occasionally push their work either to their personal central mirror or use their personal branches in
  a central repo; in this case the integrators pull their work from there.

• Integrators do actual integration and update the central repo.

  No one except those folks is able to commit there, only fetch.

Of course, this approach requires certain mind bending. Linus Torvalds gave a good and lengthy explanations of this alternative mindset while helping KDE folks migrate from their CVCS to Git [2].

1. https://github.com/sitaramc/gitolite
2. http://lwn.net/Articles/246381/