Git: Access Control? How to do in practice

Question

how would one protect a GIT repository of a complete (java) application from having a developer getting access to all the source code in the repository. I know GIT is a distributed Versioning Control where a developer normally "downloads/fetches" the complete(!) repository.

My Questions:

1. How to sperate "modules/autonomous parts" in git? For example havng a module "payment layer" and "database layer" and "processing layer" and so forth all abstracted via APIs/Interfaces. Do i have to setup a seperate git repository for all those modules?

2. Is there a way to have one large repository in GIT but to somehow restrict the access by path? (A client should only recive those files he was granted access to)

3. Is there a way to have one large repository in GIT but to somehow restrict the access by Branch/Tags? (A client should only recive those files he was granted access to)

4. Just in Case someone knows this too: Is there a way in eclipse to chekout content from multiple GIT repositories into one project and also (the other way round) commit code within in one eclipse project to multiple different GIT repositories (based on package names/paths or in the context menu)?

Thank you very much Markus!

Answer 1

1. You will have to split up the code into multiple git repositories if you want differential control. You cannot control by branches or whatever. Git downloads the entire repo. Period.

2. You can look into git modules for a mechanism for making it easier to work with a thing built of multiple git repositories.

Answer 2

1) and 4) depends a lot of your build evironment. In git you try to have separate repositories per modules, but if the setup of the source tree becomes painful you can use git submodules (though not much people like them) or the repo tool the Android project uses. This allows you to have an "umbrella" project composed of more subprojects. Not sure if it is worth it for just a few components. Just one git repo may still make more sense.

For questions 2) and 3):

For access, I would recommend that every sub-team keeps its own fork (repository) and somebody reviews what they push to the integration repository. If you don like this approach, you can use git server hooks to enforce policies writing scripts.

In this case, the hook could check who is pushing, and the path or refspec (branch) against some config file describing the policy. This is documented here:

https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy