Git 部分复制访问控制 [英] Git Partial Copy Access Control

问题描述

我必须部署一个 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.

众所周知，这个工作流程很难在纯 git 中实现，因为 git 假设项目中的每个人都可以访问存储库，在任何情况下都可以使用克隆命令访问整个存储库.通过构造及其分布式特性，git 的最低用户权限是只读访问权限.

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.

互联网上推荐了几种方法来解决这个问题，特别是使用子模块，将每个团队分开在一个单独的存储库下.然而，像子模块、子树和 subrepos 项目这样的解决方案都带来了一些不可取的集成和管理复杂性.事实上，使用 git 功能的子模块作为访问控制系统似乎是一种误用.

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.

经过研究，我得出结论，Gitolite 可以成为实现我想要的目标的可行工具.Gitolite 有一个称为部分复制的功能，它根据一组用户的规则集拒绝特定分支的访问.如果您定义用户bob"将仅具有对主项目foo"的partialCopy"下的unstable"分支的 RW+ 访问权限，那么集成开发人员john"可以将机密代码推送给 master，而无需担心'鲍勃' 读它.实际上，'bob' 甚至不会知道 master 分支下的文件存在.

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.

然而，Gitolite 是一种准系统方法，需要对存储库、用户密钥和权限文件进行低级别管理.

However, Gitolite is a barebone approach, requiring low level management of repositories, user keys and permission files.

考虑到所有这些:在任何最好的 git 套件解决方案(如 GitHub、GitLab、Bitbucket、CodeCommit 等)下，是否有与 部分复制 功能类似的功能?

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?

目标是部署一个 git 套件，为非技术经理提供更好的存储库管理、云支持、工具集成和 GUI 访问，以及与 Gitolite 相同的细粒度访问控制.

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.

部分副本似乎只适用于分支.为了使这对您有用，您需要从孤立的分支中删除已经存在的受保护代码，这将导致集成问题更严重.要做到这一点而不授予对原始文件的访问权限，您需要创建一个 baseless 分支，因为一个分支被定义为一个给定的提交，并且所有提交都可以从该提交访问.

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.

创建一个 baseless 分支会引入一个额外的问题，即在没有共同祖先的情况下进行合并，并且无法在不合并旨在隔离的代码的情况下轻松共享对不同分支中的公共文件所做的更改.在从其他系统进行迁移时，我在使用 baseless 分支方面的经验有限，所以我什至不确定它会如何处理独立行中丢失的主行中的这么多文件.

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.

从逻辑上讲，这与在单独的存储库中实现子模块相同，只是使用第三方工具进行访问，因此它会带来相同的集成和管理开销(如果不是更多，则与 git 的本机设计背道而驰).

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屋！