管理 GIT 权限 - 多个存储库

Question

我们有几个开发团队，每个团队开发多个项目（通常超过 10 个）。我们目前正在 CVS 中评估是否迁移到 SVN 或 GIT。我倾向于 GIT，但我不确定我们如何有效地管理权限。例如。

我们有开发团队 A、开发团队 B、开发团队 C。每个团队都有 12 名开发人员。每个开发团队至少有 10 个独立的项目。 A队可以看到每个人的代码，B队和C队只能看到他们的代码。此外，一些开发人员只有只读访问权限，而其他开发人员具有完全访问权限。

所以在 CVS 中，我们有三个存储库，每个团队一个。所以它就像：

/cvsroot/TeamARepos/project1
/cvsroot/TeamARepos/project2

/cvsroot/TeamBRepos/project1
/cvsroot/TeamBRepos/project2 

/cvsroot/TeamCRepos/project1
/cvsroot/TeamCRepos/project2 

等等。我可以管理整个存储库，并说 John Doe 对 A 有只读访问权限，但对 B 有写访问权限，对 C 没有访问权限 - 因此我不必让他显式访问每个项目（而且它们经常被添加，所以我不必每次都将每个人都添加到每个新项目中）。

我对 GIT 的理解是每个项目都有一个存储库。因此，没有一种真正合乎逻辑的方式可以说“A 团队的所有代码都在这里，这些用户可以写入”和“B 团队的所有代码都在这里，这些用户可以阅读”并像这样分开。

我不确定我什至知道如何正确地提出这个问题 - 但我认为迁移到 GIT 是一场管理噩梦。

我们还使用 ant 脚本从 CVS 中检查代码、进行构建并部署到服务器。我刚开始看，但我希望 ant 在这个意义上也能很好地与 GIT 配合使用。

Answer 1

如果您想在多个项目中查看所有团队 A 的代码，您可以创建一个包含所有代码库的远程代码的包罗万象的代码库，只需 git fetch --all，然后进行分析。

Gitolite 使管理（到自定义挂钩）变得轻而易举。它使您可以控制谁可以读取或写入分支。您甚至可以实现自己的 git 钩子以实施其他自定义安全措施，例如确保每个人在每个提交消息中都包含票证参考。我在过去 2 年多的时间里一直在使用它，非常棒。

我们从 SVN 迁移到 Git 是因为解决冲突的痛苦、速度和许多其他原因，其中之一是 git 的采用率。在 rerere 中存储分辨率可以轻松混合和匹配特征。 Hooks 很容易编写，我们可以在某些包含代码合约的 repos 上强制执行 OCP。所有这些在 SVN 中都是非常麻烦的——如果不是不可能的话。

根据 CI 流程，git 在命令行中运行良好，因此您可以在任何自动构建工具中做您喜欢的事情。现在对此类所有主要工具的支持都是开箱即用的。

这是我们使用 git 在每个存储库中遵循的过程：http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Answer 2

Subversion 对您来说可能是一种更顺畅的方式（至少在以后的迁移和管理领域）。

“Merge Hell”对于 Git 男孩和懒惰的不合格 SVN 用户来说是一个大肆宣传的神话和忌讳。好吧，它在某些条件下确实存在（以“重构地狱”的形式适用于任何质量的团队），您只需要检测这种条件是否适用于您的工作流程。

您对现有的服务器操作系统和基础设施一无所知，但在某些情况下它很重要。 Git 服务器和 Win 下的一些前端是真正的噩梦和恐怖，fe，对于 Linux 端，我找不到这样紧凑且可用的 Subversion over http 解决方案，如适用于 Windows 的 VisualSVN 服务器（企业版）（UberSVN 从我的 POV 来看过于臃肿） ）。如果您在服务器上有 Java，您可以考虑（对于您的团队的规模和 repos 的数量）关于 SCM-manager（对于 任何 选择的 SCM - 它支持 Git、SVN、Hg 从一个盒子）

Answer 3

我建议使用 git 而不是 svn，因为它的速度、分布式版本控制模型和整体上理智的做事方式。我们在工作中使用 SVN 有几年了，与 git 相比，这真的很痛苦。我看到 SVN 的唯一优势是它与 Windows 的集成，例如TortoiseSVN。但这只是你喜欢受 GUI 约束，不愿意学习更强大的命令行的情况。

使用 git 你显然需要gitolite 来处理访问控制。使用此模型，您可以为每个项目设置不同的存储库。 Gitolite 配置文件允许您将开发人员分组到团队中，然后您可以为每个存储库、分支甚至工作树路径设置非常细粒度的访问控制。您可以按照最适合您的方式指定团队或个人的权限。

如果您需要代码审查，您还应该检查gerrit 是否适合您。你不需要两者，使用 gitolite 或 gerrit。

有时人们发现 git 很难学。为此，我建议向开发人员介绍一本好书，例如this。它也有印刷版。