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

741
Michael

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

0

1 ответ на вопрос

0
wrksprfct

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

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

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

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

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

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

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

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

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

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

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

Удачи!