Grupos e subgrupos de múltiplos repositórios git?

0

Atualmente, tenho alguns repositórios SVN, e é assim:

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

Eu gostaria de fazer a transição de tudo isso para o git, de alguma forma. Então, eu provavelmente terei alguns repositórios:

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

o problema agora é que eles estão todos no mesmo nível de hierarquia. Eu gostaria de colocar os repositórios git em alguma hierarquia, como

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

Existe uma ferramenta que me permite gerenciar centenas de repositórios git e me permite categorizar os repositórios em grupos aninhados? Não consigo ver como conseguir isso, por exemplo, com o GitHub. Eu gostaria de poder definir políticas de acesso para grupos (e não apenas repositórios únicos). Por exemplo. Gostaria de dizer que User1, User2 e User3 podem ler / gravar no Customer1, e User4-User6 pode ler / gravar no Customer2, e User1-User6 pode ler todos os repos, e o User7-8 pode ler / gravar todos os repos. User9 é admin para tudo em Customer2 e User10 é superusuário.

Eu não me importo como os repositórios são realmente armazenados no sistema de arquivos do servidor. Fico feliz se tiver apenas uma interface que finja que eles estão organizados em grupos e onde posso definir diretivas de acesso em todas as "pastas". Se as URLs reais do repositório git também refletirem a estrutura do projeto visível, seria bom.

Ou qualquer sugestão de como ser um administrador para mais de 100 repositórios git sem enlouquecer seria bem-vinda.

    
por Michael 01.11.2015 / 00:01

1 resposta

0

Você está perguntando sobre como organizar o Git repos por pastas (aninhadas) para fins de agrupamento / navegação e permissões. Vamos falar sobre permissões primeiro.

As ferramentas que o GitHub e o Bitbucket fornecem para gerenciar usuários e grupos são bastante flexíveis e podem certamente satisfazer suas necessidades. Na verdade, você pode se safar com algo relativamente simples.

Por exemplo: primeiro crie uma organização ou equipe para sua empresa. Em seguida, crie grupos que espelhem os clientes (e / ou os projetos), adicione os usuários desejados ao grupo e conceda a permissão de grupo ao repositório. (IIRC, BB permite que cada usuário em um grupo tenha diferentes níveis de acesso, enquanto GH atribui ao grupo inteiro o mesmo nível de acesso.)

Ou você pode organizar grupos por equipes funcionais (desenvolvedores de iOS, desenvolvedores de servidores, etc.) ou de alguma outra forma que faça sentido para sua empresa. (Em teoria, você também pode criar uma única organização / equipe para cada cliente, cada um com seus próprios grupos, caso precise.)

A chave para manter a flexibilidade e a sanidade é organizar as equipes em grupos gerenciáveis e, em seguida, conceder às equipes necessárias acesso aos repositórios. Muitas equipes podem ter acesso a um único repo. No entanto, como não há hierarquia, não há oportunidade para herança de permissões.

O caso de uso de superusuário também é facilmente endereçável: crie uma equipe de 'superusuários' para garantir acesso a todos os repositórios. BB ainda tem padrões que são aplicados ao criar novos repositórios.

Agora, para a organização ...

Ainda não encontrei uma interface web do Git que permita a organização baseada em pastas do Git repos. O modelo GH & O BB segue: equipe (organização) → repos. Talvez um dia eles adicionem tags ou outros metadados em repositórios que possam ser usados para organização.

A abordagem de navegação comum adotada pelo GH & BB é uma lista de filtragem / pesquisa, que, como você pode imaginar, depende de uma estrita estratégia de nomeação para ser eficaz.

Outra coisa que pode influenciar seu esquema de organização é a emissão de tickets e o uso do wiki. Ingressos e wikis são por projeto (repo) na GH & BB, e pode ser desativado. Se você tiver ferramentas externas (JIRA e Confluence, talvez), não há uma preocupação real.

A ferramenta Git para importar repositórios SVN é bastante flexível, então você deve ser capaz de persuadi-lo para lidar com sua situação sem muito esforço.

Boa sorte!

    
por 06.11.2015 / 07:21