问题
I have to deploy a Git repository where several development teams will work together in independent blocks of code. We have a main in-house integration team that can access everything from everyone. However, some third-party developers should not be able to access top level data and code from our company.
It is known that this workflow is difficult to implement in pure git because git assumes that everyone inside a project, with common access to a repository, can access the entire repository with a clone command, under any circunstancies. By construction and its distributive nature, git's lowest user permission is read-only access permission.
Several approaches are recommended over the Internet do deal with this problem, specially with the use of submodules, separating each team under an individual repository. However, solutions like submodules, subtrees and the subrepos project all bring several integration and management complexities that are not desirable. In fact, the use of git features such submodules as an access control system seems like a misuse.
After research, I conclude that Gitolite can be a feasible tool to achieve what I want to. Gitolite has a feature called partial copy that denies access of specific branches depending on the set of rules for a set of users. If you define that a user 'bob' will have RW+ access to only the branch 'unstable' under a 'partialCopy' of a main project 'foo', than an integrator developer 'john' could push confidential code to the master without worrying about 'bob' reading it. Actually, 'bob' will not even know that the files under master branch exist.
However, Gitolite is a barebone approach, requiring low level management of repositories, user keys and permission files.
Considering all this: Is there anything similar to the partial copy feature under any of the best git suite solutions out there like GitHub, GitLab, Bitbucket, CodeCommit, etc?
The objective is to deploy a git suite with a better repository management, cloud support, tool integration and GUI access for non-technical managers, with the same fine-grained access control found in Gitolite.
回答1:
Breaking them up into separate repositories is probably the only viable option for your situation.
Partial copy appears to only work on branches. In order for this to work for you, you'd need to remove protected code that already exists from your isolated branches which will cause far worse problems on integration. To do this without giving access to a the original files you'd need to create a baseless branch because a branch is defined as a given commit and all commits reachable from that commit.
Creating a baseless branch introduces the additional problem of merging without a common ancestor and not having the ability to easily share changes to common files made in different branches without merging in code that is intended to be isolated. I've only had limited experience working with baseless branches while doing migrations from other systems, so I'm not even sure how it would deal with so many files in the main line being missing from the isolated line.
Logically, this is the same as implementing submodules in separate repositories, just with a third party tool for access, so it will come with the same integration and management overhead (if not more by running counter to the native design of git).
Addressing some of your concerns, sub-modules are not nearly as bad as many people make out, they are just a little awkward until you get used to them.
If this is not preferred. Using a packages and a package managers is also a good option here if there are a lot of shared components. This gives people access to the functionality without necessarily giving them access to the code if you're working in a compiled language and read-only access to the code in an interpreted language. (I've used this on several very large projects.)
Using multiple repositories for access control is just a slightly more formalized version of the lieutenant/benevolent dictator model used on many very large projects like the Kernel. This keeps your repositories light and manageable as well.
回答2:
Your understanding isn't quite correct. Gitolite's partial copy feature simply creates another repository that is contains all but the forbidden branches. Pushes to the main repository are auto-pushed to the partial copy repo and pushes to the partial copy repo are pushed back to the main repo.
Gitolite is really just a set of very good perl wrappers around git to facilitate access control, etc. As such, there is no magic there. (For example, some tools like gerrit that re-implement their own git server can do clever things with refs. gitolite does no such things, it uses stock git.) So anything that gitolite does, you should be able to do yourself, if you really want to.
You can see how gitolite does it in the two scripts below. As per the documentation I linked to, the VREF is executed as an 'update hook' for the partial copy repo. The trigger code is executed as a 'post-receive hook' for the main repository.
https://github.com/sitaramc/gitolite/blob/master/src/VREF/partial-copy https://github.com/sitaramc/gitolite/blob/master/src/triggers/partial-copy
I would imagine you could implement this yourself on any git hosting software that allows you to install your own hooks. The only change you would need to make is that the gitolite access function would not be there, you would need to write something yourself to encode the branch rules that you want.
来源：https://stackoverflow.com/questions/48301882/git-partial-copy-access-control