Группы и подгруппы из нескольких git-репозиториев?

Question

В настоящее время у меня есть несколько репозиториев 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) ...

Я хотел бы как-нибудь перевести все это на мерзавец. Итак, у меня, вероятно, будет несколько репозиториев:

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 является суперпользователем.

Мне все равно, как хранилища на самом деле хранятся в файловой системе серверов. Я счастлив, если у меня просто есть интерфейс, который притворяется, что они аккуратно организованы в группы, и где я могу устанавливать политики доступа для целых "папок". Если фактические URL-адреса репозитория git также отражают видимую структуру проекта, было бы неплохо.

Или любые советы о том, как быть администратором для 100+ git-репозиториев, не сходя с ума, будут приветствоваться.

Answer 1

Вы спрашиваете об организации репозиториев Git по (вложенным) папкам для группирования / просмотра и получения разрешений. Давайте сначала поговорим о разрешениях.

Инструменты GitHub и Bitbucket, предназначенные для управления пользователями и группами, достаточно гибки и, безусловно, могут удовлетворить ваши потребности. На самом деле, вы можете уйти с чем-то относительно простым.

Например: сначала создайте организацию или команду для вашей компании. Затем создайте группы, которые отражают клиентов (и / или проекты), добавьте нужных пользователей в группу, а затем предоставьте группе разрешение на репо. (IIRC, BB позволяет каждому пользователю в группе иметь разные уровни доступа, в то время как GH назначает для всей группы один и тот же уровень доступа.)

Или вы можете организовать группы по функциональным командам (разработчикам iOS, разработчикам серверов и т.д.) Или другим способом, который имеет смысл для вашего бизнеса. (Теоретически, вы также можете создать одну организацию / команду для каждого клиента, каждый со своими группами, если вам это нужно.)

Ключ к поддержанию гибкости и здравомыслия состоит в том, чтобы организовать группы в управляемые группы, а затем предоставить требуемым группам доступ к репозиториям. Многим командам может быть предоставлен доступ к одному репо. Однако, поскольку нет иерархии, нет возможности для наследования разрешений.

Вариант использования суперпользователя также легко доступен: создайте команду «суперпользователь», предоставив ей доступ ко всем репозиториям. BB даже имеет значения по умолчанию, которые применяются при создании новых репо.

Теперь к организации ...

Я еще не сталкивался с веб-интерфейсом Git, который позволяет организовать репозитории Git на основе папок. Модель GH & BB следующая: команда (организация) → репо. Возможно, однажды они добавят теги или другие метаданные в репозитории, которые можно использовать для организации.

Обычный навигационный подход, используемый GH & BB, - это фильтрация / поиск списков, который, как вы можете себе представить, полагается на строгую стратегию именования репо, чтобы быть эффективной.

Еще одна вещь, которая может повлиять на схему вашей организации, это использование билетов и использование вики. Билеты и вики для каждого проекта (репо) на GH & BB, и могут быть отключены. Если у вас есть внешние инструменты (возможно, JIRA & Confluence), в этом нет особой проблемы.

Инструмент Git для импорта репозиториев SVN достаточно гибок, поэтому вы сможете использовать его для решения вашей ситуации без особых усилий.

Удачи!