☰

多个 git 存储库的组和子组？

tag-icon • tag-icon git version-control
多个 git 存储库的组和子组？

目前，我有几个 SVN 存储库，它们看起来像这样：

Customer1 (this is a proper "SVN Repository")
    project1
        foo82
            trunk
            tags
            branches
        bar01
            trunk
            tags
            branches
    project2
        ...
    project3 ...
    ...
Customer2 (this is a proper "SVN Repository")
    tool1
        windows-version
            trunk
            tags
            branches
        mac-version
            trunk
            tags
            branches
        server-component
            trunk
            tags
            branches
        ios-app
            trunk
            tags
            branches
    tool2
        (same subfolders as tool1)
    tool3
        (same subfolders as tool1 with slight modifications)
Customer3
    (similarily complicated folder structure)
... (about 5 more customers) ...

我想以某种方式将所有这些转移到 git。因此，我可能会有几个存储库：

foo82
bar01
tool1-windows-version
tool1-mac-version
tool1-server-component
tool1-ios-app
tool2-windows-version
tool2-mac-version
tool2-server-component
tool2-ios-app
... (150 more projects) ...

现在的问题是它们都处于同一层次结构中。我想将 git 存储库放入某个层次结构中，例如

Customer1 (this is not a repository, just a folder!)
    project1 (this is not a repository, just a folder!)
        foo82.git (this is a git repository)
        bar01.git
    project2 (this is not a repository, just a folder!)
        ... (here lie a bunch of git repositories)
Customer2 (this is also not a git repository, just a folder!)

有没有一种工具可以让我管理数百个 git 存储库，并允许我将存储库分类为嵌套组？我看不出如何实现这一点，例如，使用 GitHub。我希望能够为组（而不仅仅是单个存储库）定义访问策略。例如，我想说 User1、User2 和 User3 可以读取/写入 Customer1，User4-User6 可以读取/写入 Customer2，User1-User6 可以读取所有存储库，User7-8 可以读取/写入所有存储库。User9 是 Customer2 下所有存储库的管理员，而 User10 是超级用户。

我并不关心存储库在服务器文件系统上的实际存储方式。只要有一个界面假装它们整齐地组织成组，并且我可以在整个“文件夹”上设置访问策略，我就很高兴了。如果实际的 git 存储库 URL 也反映了可见的项目结构，那就太好了。

或者，如果您能提供任何关于如何成为 100 多个 git 存储库的管理员而不会发疯的提示，我们将不胜感激。

答案1

您询问的是按（嵌套）文件夹组织 Git 存储库以便进行分组/浏览和权限管理。我们先来谈谈权限。

GitHub 和 Bitbucket 提供的管理用户和群组的工具非常灵活，一定能满足您的需求。事实上，您可能只需要做些相对简单的事情。

例如：首先为您的公司创建一个组织或团队。然后创建镜像客户（和/或项目）的组，将所需用户添加到该组，然后授予该组对存储库的权限。（如果我没记错的话，BB 允许组中的每个用户拥有不同的访问级别，而 GH 为整个组分配相同的访问级别。）

或者您可以按功能团队（iOS 开发人员、服务器开发人员等）或其他适合您业务的方式组织群组。（理论上，如果需要，您还可以为每个客户创建一个组织/团队，每个组织/团队都有自己的群组。）

保持灵活性和合理性的关键是将团队组织成可管理的组，然后授予所需团队对存储库的访问权限。可以授予多个团队对单个存储库的访问权限。但是，由于没有层次结构，因此没有权限继承的机会。

超级用户用例也很容易解决：创建一个“超级用户”团队并授予其访问所有存储库的权限。BB 甚至具有在创建新存储库时应用的默认值。

现在开始组织...

我还没有遇到过允许基于文件夹组织 Git 存储库的 Git Web 界面。GH 和 BB 遵循的模型是：团队（组织）→存储库。也许有一天他们会在存储库上添加可用于组织的标签或其他元数据。

GH 和 BB 采用的常见导航方法是列表过滤/搜索，你可以想象，它依赖于严格的 repo 命名策略才能有效。

另一个可能影响您组织方案的因素是票证和 Wiki 的使用。票证和 Wiki 是 GH 和 BB 上每个项目 (repo) 的，可以禁用。如果您有外部工具（可能是 JIRA 和 Confluence），则无需担心。

用于导入 SVN 存储库的 Git 工具相当灵活，因此您应该能够轻松使用它来处理您的情况。

祝你好运！

相关内容