Yes, I know I know hehe. A Distributed Version Control System doesn't has a central repository, anyone can get the versions of any repository because this is not a centralized VCS. However in real life in an office, often the bosses want to be the masters of everything, so I've come here to see if anyone has a good approach in my case.
At my office we have started to use GIT,and we have something like this:
<SERVER>
---->../apache/htdcos/All_Proyects [Bare repository]
-------->/Proyect_A [Repository]~~~ Developer 1 [Git Repo], Developer 2 [Git Repo]
-------->/Proyect_B [Repository]~~~ Developer 3 [Git Repo], Developer 4 [Git Repo]
-------->/Proyect_123 [Repository]~~~ Developer 5 [Git Repo], Developer 6 [Git Repo]
The idea it's that every project has it's own GIT repository and in the All_Projects folder it could have a Bare Repository then "main one" so all projects push to it;that bare repository would be something like the master of masters repository (Is this really a good approach in the first place???)
With this approach I have some doubts...
How can I have a hierarchy of users/repositories?? So, for example, Developer 5 can't push/pull/commit from/to Proyect_A but he can do it to his own Proyect_123??
Can I have a hierarchy system something like these?: Developer pushes to Boss repository, Boss pushes to project repository and Server automatically (cron maybe) pulls from every project repositories to the bare master of masters repository. (Where developer can't push directly to bare repository).
How can I do something like that? THANKS!
Repos referenced by a parent repo are exactly why submodules are for.
And protection by users and by project is possible, provided you have added to your main Git repos server Gitolite (see installation page).
It is a small collection of Perl scripts which will intercept any Git command and will validate said command against a configuration file which specifies which user can do what on which repo.