git-目录访问控制 [英] git - Access Control on directories

问题描述

是否可以在git中控制其他目录?

Is it possible to control different directories in git?

我有一个Java项目，其中包含许多文件夹(实际上是软件包)，可以为团队分配工作. "Team Alpha"必须能够查看和更改程序包"alpha"，而"Team Beta"必须能够查看和更改程序包"beta".但是团队alpha 甚至看不到 beta版程序包中的代码，只是作了更改.

I have a java project with many folders (packages in fact) which divides the work for the team. "Team Alpha" must be able to see and change package "alpha" and "Team Beta" must be able to see and change package "beta". but team alpha can not even see the codes in package beta, changing aside.

考虑到该项目是一个整体，并且为了进行编译和运行，必须同时包含alpha和beta软件包，有没有办法控制这个项目?

Considering that the project works as a whole and for compiling and running it both alpha and beta packages must be present, is there a way to control this ?

另一个问题:模块化设计是一种选择，对吗?整个项目都可以使用alpha和beta软件包的编译版本，团队alpha具有已编译的beta软件包，然后反向进行...如果没有，为什么?

Another question : modular design is an option,right? whole project can work with compiled versions of alpha and beta packages, team alpha has the compiled beta package and reverse... if no,why?

推荐答案

某些背景

虽然 gitolite 之类的工具可能会控制谁可以对存储库执行操作(出现gitolite成为事实上的标准低级解决方案)，它们只处理整个存储库.

Some background

While tools like gitolite might control who can do what with the repositories (gitolite appears to be the de facto standard low level solution for this), they only deal with whole repositories.

原因:

• 在分布式版本控制系统中:

• In a distributed version control system:

• 每个提交代表整个存储库的状态.
• 您无法克隆提交的一部分.即使可以，也无法验证历史记录的完整性(由于缺少对象).
• 每个人都有完整的存储库克隆(好吧，使用Git，您可以克隆足够多的对象以仅进行一次提交或几个提交，但这是深度限制"操作，而不是宽度限制").

因此，首先要知道的是，在DVCS中实现按目录的访问控制在技术上是行不通的:拥有此选项将仅允许全部或全部"访问:您总体上具有读取(或写入)权限存储库或没有此权限.像gitolite这样的工具可以做到这一点.

So, the first thing to know is that implementing per-directory access controls are technically infeasible in a DVCS: having this option would only allow "all or nothing" access: either you have read (or write) permission on the whole repository or do not have this permission. Tools like gitolite can do that.

Git根本不跟踪目录.这是一件很奇怪的事情，但这是事实.这就是为什么您不能向Git添加空目录的原因.仅当目录中的文件被跟踪时才跟踪目录(以所谓的树对象"的形式)，而当这些文件从版本控制中删除时，目录才被跟踪.也就是说，仅由于现代流行的文件系统是分层的，所以目录跟踪才存在，而Git必须处理此问题.

Git does not track directories at all. This is a weird thing to learn but it's true. That's why you can't add an empty directory to Git. The directories only become tracked (in the form of so-called "tree objects") when files located in them become tracked and end being tracked when those files are removed from version control. That is, tracking of directories is there only because contemporary popular filesystems are hierarchical, and Git has to handle this.

这不是设计监督，而是有意识的设计决策.您可以阅读Git创建者本人在文件"中所说的内容. VS内容"辩论.

This is not some design oversight but rather a conscious design decision. You can read what the Git creator himself said on the "files vs content" debate.

因此，第二件事要知道，将任何管理"含义附加到目录上显然要面对在Git中如何管理项目的想法.

So, the second thing to know is that attaching any "administrative" meaning to directories explicitly confronts the very idea of how a project is managed in Git.

使用子模块.

说，如果您的团队α和β应该具有单独的代码库，但其他一些项目同时使用这两个代码库，将α和β的代码库放入单独的存储库中，并且使用它们的项目也使用单独的存储库，该存储库使用子模块来引用这两个依赖的项目上.

Say, if your teams α and β should have separate code bases but some other project uses both of them, make α's and β's code bases into separate repositories and the project which uses them also a separate repository which uses submodules to refer to these two projects it depends on.

子模块的一个属性是子模块引用始终引用相应存储库中的确切提交，因此您的第三个(从属)存储库中的每个提交都将引用α和β代码库的确切状态，在任何过去的时间点提供可复制的版本.

A property of submodules is that a submodule reference always refers to exact commit in the corresponding repository, so each commit in your third (dependent) repository will refer to exact states of α's and β's code bases, providing reproducible builds at any past point.

这篇关于git-目录访问控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！