Git部分复制访问控制 [英] Git Partial Copy Access Control
问题描述
我必须部署一个Git存储库，其中几个开发团队将在独立的代码块中一起工作。我们有一个主要的内部集成团队，可以从所有人那里访问所有内容。但是，某些第三方开发人员应无法从我们公司访问顶级数据和代码。
众所周知，此工作流程很难在纯git中实现，因为git假定项目中的每个人（对存储库具有公共访问权限）都可以使用任何情况下的克隆命令。根据构造及其分发性质，git的最低用户权限是只读访问权限。
在Internet上建议使用几种方法来解决此问题，特别是使用子模块将每个团队分隔在一个单独的存储库中。但是，诸如子模块，子树和子仓库项目之类的解决方案都会带来一些不希望的集成和管理复杂性。实际上，将git功能之类的子模块用作访问控制系统似乎是一种滥用。
经过研究，我得出结论，Gitolite可以成为实现我想要的目标的可行工具。 Gitolite具有称为部分复制的功能，该功能会根据一组用户的规则集拒绝对特定分支机构的访问。如果您定义用户 bob仅对主项目 foo的 partialCopy下的不稳定分支具有RW +访问权限，则集成开发人员 john可以将机密代码推送给主服务器，而无需担心鲍勃正在阅读。实际上， bob甚至都不知道master分支下的文件存在。
但是，Gitolite是一种准系统方法，需要对存储库，用户密钥和权限文件进行低级管理。
考虑所有这些：在GitHub，GitLab，Bitbucket，CodeCommit等最佳的git套件解决方案下，是否有与部分复制功能相似的东西？
目标是为非技术经理部署具有更好的存储库管理，云支持，工具集成和GUI访问的git套件，并具有相同的细粒度访问权限
将它们拆分成单独的存储库可能是您所处情况的唯一可行选择。
部分副本似乎仅适用于分支机构。为了使它起作用，您需要从隔离的分支中删除已经存在的受保护代码，这将导致集成方面的严重问题。为此，在不访问原始文件的情况下，您需要创建一个无基础的分支，因为分支定义为给定的提交，并且所有提交都可以从该提交到达。
<创建无基础分支会带来另外的问题，即在没有公共祖先的情况下进行合并，并且无法轻松共享对不同分支中进行的公共文件所做的更改，而无需合并要隔离的代码。从其他系统进行迁移时，我对使用无基础分支的经验很有限，所以我什至不确定如何处理主行中孤立行中丢失的这么多文件。
从逻辑上讲，这与在单独的存储库中实现子模块相同，只是具有用于访问的第三方工具，因此它将具有相同的集成和管理开销（如果不这样做的话，将产生更多的开销）。
为解决您的一些问题，子模块的功能不如许多人想象的那么糟糕，在您遇到之前，它们有点尴尬。
如果不希望这样做的话。如果有很多共享组件，使用包和包管理器也是一个不错的选择。如果您使用的是编译语言，这使人们可以不必使用代码就可以访问该功能，而使用解释性语言则可以对它们进行只读访问。 （我已经在几个非常大的项目中使用了它。）
使用多个存储库进行访问控制只是用于中尉/仁慈独裁者模型的形式化版本许多非常大的项目，例如内核。这也使您的存储库更轻巧且易于管理。
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.
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.
这篇关于Git部分复制访问控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
