Gruppen und Untergruppen mehrerer Git-Repositories?

Derzeit habe ich ein paar SVN-Repositories und es sieht so aus:

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

Ich würde das alles gerne irgendwie auf git umstellen. Also werde ich wahrscheinlich ein paar Repositories haben:

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

Das Problem ist nun, dass sie alle auf der gleichen Hierarchieebene sind. Ich möchte die Git-Repositories in eine Hierarchie wie platzieren

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

Gibt es ein Tool, mit dem ich Hunderte von Git-Repositorys verwalten und die Repositorys in verschachtelte Gruppen einteilen kann? Ich kann nicht sehen, wie das zB mit GitHub erreicht werden kann. Ich möchte Zugriffsrichtlinien für Gruppen (und nicht nur für einzelne Repositorys) definieren können. Ich möchte beispielsweise sagen, dass Benutzer1, Benutzer2 und Benutzer3 Kunden1 lesen / schreiben können und Benutzer4-Benutzer6 Kunden2 lesen / schreiben können und Benutzer1-Benutzer6 alle Repos lesen / schreiben können und Benutzer7-8 alle Repos lesen / schreiben kann. User9 ist der Administrator für alles unter Customer2 und User10 ist der Superuser.

Es ist mir egal, wie die Repositorys tatsächlich auf dem Dateisystem des Servers gespeichert sind. Ich bin froh, wenn ich nur eine Oberfläche habe, die so tut, als wären sie ordentlich in Gruppen organisiert, und auf der ich Zugriffsrichtlinien für ganze "Ordner" festlegen kann. Wenn die tatsächlichen Git-Repository-URLs auch die sichtbare Projektstruktur widerspiegeln, wäre es schön.

Oder irgendwelche Tipps, wie man ein Administrator für über 100 Git-Repositories ist, ohne verrückt zu werden.

Sie möchten Git-Repos nach (verschachtelten) Ordnern organisieren, um sie zu gruppieren / durchsuchen und Berechtigungen zu erteilen. Lassen Sie uns zuerst über Berechtigungen sprechen.

Die Tools GitHub und Bitbucket zum Verwalten von Benutzern und Gruppen sind recht flexibel und können sicherlich Ihre Anforderungen erfüllen. Tatsächlich sind Sie möglicherweise in der Lage, mit etwas relativ Einfachem davonzukommen.

Beispiel: Erstellen Sie zunächst eine Organisation oder ein Team für Ihr Unternehmen. Erstellen Sie dann Gruppen, die die Kunden (und / oder die Projekte) spiegeln, fügen Sie der Gruppe die gewünschten Benutzer hinzu, und erteilen Sie dem Repo dann die Gruppenberechtigung. (Mit IIRC, BB kann jeder Benutzer in einer Gruppe unterschiedliche Zugriffsebenen haben, während GH der gesamten Gruppe dieselbe Zugriffsebene zuweist.)

Oder Sie können Gruppen nach Funktionsteams organisieren (iOS-Entwickler, Server-Entwickler usw.) oder auf eine andere Weise, die für Ihr Unternehmen sinnvoll ist. (Theoretisch können Sie auch für jeden Kunden eine Organisation / ein Team mit jeweils eigenen Gruppen erstellen, falls Sie dies benötigen.)

Der Schlüssel zur Aufrechterhaltung von Flexibilität und Vernunft besteht darin, Teams in überschaubaren Gruppen zu organisieren und den erforderlichen Teams dann Zugriff auf die Repos zu gewähren. Vielen Teams kann der Zugriff auf ein einzelnes Repo gewährt werden. Da es jedoch keine Hierarchie gibt, gibt es keine Möglichkeit zur Vererbung von Berechtigungen.

Der Superuser-Anwendungsfall ist ebenfalls leicht zu adressieren: Erstellen Sie ein Superuser-Team, das Zugriff auf alle Repos gewährt. BB hat sogar Standardeinstellungen, die beim Erstellen neuer Repos angewendet werden.

Nun zur Organisation ...

Ich bin noch nicht auf ein Git-Webinterface gestoßen, das die ordnerbasierte Organisation von Git-Repos ermöglicht. Das Modell von GH & BB lautet: Team (Organisation) → Repos. Vielleicht fügen sie eines Tages Tags oder andere Metadaten zu Repos hinzu, die für die Organisation verwendet werden können.

Der übliche Navigationsansatz von GH & BB ist das Filtern / Suchen von Listen. Wie Sie sich vorstellen können, beruht dieser Ansatz auf einer strikten Strategie für das Reponamen, um effektiv zu sein.

Eine andere Sache, die Ihr Organisationsschema beeinflussen kann, ist das Ticketing und die Wiki-Nutzung. Tickets und Wikis sind pro Projekt (Repo) auf GH & BB und können deaktiviert werden. Wenn Sie externe Tools haben (JIRA & Confluence, vielleicht), gibt es keine wirklichen Bedenken.

Das Git-Tool zum Importieren von SVN-Repos ist ziemlich flexibel, sodass Sie es ohne großen Aufwand an Ihre Situation anpassen können sollten.

Viel Glück!