Groups and subgroups of multiple git repositories?

Question

Currently, I have a few SVN Repositories, and it looks like this:

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) ...

I would like to transition all of that to git, somehow. So, I will probably have a few repositories:

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) ...

the problem is now that they are all on the same hierarchy level. I would like to place the git repositories into some hierarchy, like

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!)

Is there a tool that allows me to manage hundreds of git repositories, and lets me categorize the repositories into nested groups? I cannot see how to achieve this, e.g., with GitHub. I would like to be able to define access policies for groups (and not just single repositories). E.g. I would like to say User1, User2 and User3 may read/write to Customer1, and User4-User6 may read/write to Customer2, and User1-User6 may read all repos, and User7-8 may read/write all repos. User9 is admin for everything under Customer2, and User10 is superuser.

I don't care how the repositories are actually stored on the servers filesystem. I'm happy if I just have an interface that pretends that they are neatly organized into groups, and where I can set access policies on whole "folders". If the actual git repository URLs reflect the visible project structure too, it would be nice.

Or any tips on how to be an admin for 100+ git repositories without going insane would be appreciated.

Answer 1

You're asking about organizing Git repos by (nested) folders for grouping/browsing and permissions purposes. Let's talk about permissions first.

The tools GitHub and Bitbucket provide for managing users and groups are quite flexible and can certainly satisfy your needs. In fact, you may be able to get away with something relatively simple.

For example: first create an organization or team for your company. Then create groups that mirror the customers (and/or the projects), add desired users to the group, and then grant the group permission to the repo. (IIRC, BB allows each user in a group to have different access levels, while GH assigns the entire group the same access level.)

Or you could organize groups by functional teams (iOS devs, server devs, etc.) or some other way that makes sense for your business. (In theory, you could also make a single organization/team for each client, each with their own groups, should you need it.)

The key to maintaining flexibility and sanity is to organize teams into manageable groups and then grant the required teams access to the repos. Many teams can be granted access to a single repo. However, since there is no hierarchy, there is no opportunity for permission inheritance.

The superuser use case is also easily addressable: create an 'superuser' team abs grant it access to all repos. BB even has defaults that get applied when creating new repos.

Now on to organization...

I've not yet come across a Git web interface that allows for folder-based organization of Git repos. The model GH & BB follow is: team (organization) → repos. Maybe one day they'll add tags or other metadata on repos that can be used for organization.

The common navigation approach taken by GH & BB is list filtering/search, which, as you can imagine, relies on a strict repo naming strategy to be effective.

One other thing that may influence your organization scheme is ticketing and wiki usage. Tickets and wikis are per project (repo) on GH & BB, and can be disabled. If you have external tools (JIRA & Confluence, perhaps), there is no real concern.

The Git tool for importing SVN repos is fairly flexible, so you should be able to coax it to handle your situation without much effort.

Good luck!