Использование Git в компании?

Question

На моем рабочем месте у нас есть один большой репозиторий Subversion, который содержит около 100 проектов. Некоторые проекты используют друг друга через svn: externals. Обычно все люди имеют доступ на чтение и запись ко всему, но иногда внешние сотрудники и стажеры имеют только ограниченный доступ на чтение / запись к некоторым пользовательским папкам, поэтому они не получают наши драгоценности короны.

Как бы вы структурировали это в git? У каждого проекта свой репозиторий? как вы можете повторно использовать код? Можете ли вы как-нибудь реализовать права доступа?

Answer 1

Структура: Да, 1 проект на репозиторий. Git разработан для того, чтобы он работал таким образом, и он делает это довольно хорошо.

Повторное использование кода: Использование подмодулей git (очень похоже на svn: externals, только лучше)

Права доступа: Да, контроль доступа часто строится на ssh и открытых ключах. Если вы хотите разместить его самостоятельно, попробуйте gitosis , но я действительно очень рекомендую хостинговое решение, такое как GitHub .

Answer 2

Я бы использовал один репозиторий git, , если , вам не нужно ограничивать доступ для чтения.

Структура: Иерархия файловой системы

Повторное использование кода: через систему сборки

Права доступа: Доступ на запись - это слияние патчей. Это может контролироваться сценарием или, лучше всего, разработанным человеком. Если у вас есть как 3 проекта, у каждого есть менеджер проекта, который отвечает за слияние кода в основной ветке. Помните, что именно так работает Linux, и Git особенно хорошо подходит для этого сценария.

Зачем использовать один репо?

Основная причина - расхождение кода. Допустим, у вас есть 3 проекта и несколько общих библиотек. Команде A необходимо адаптировать интерфейс libXY и зафиксировать код по двум сценариям:

1. Подмодули: командам B и C затем придется обновить свой подмодуль и сообщить команде A, если изменения нарушили их код. Они также могут обновить код самостоятельно, но тогда у команды А также может быть некоторый разрыв кода.

2. One-big-repo: Команда A меняет код, пока не пройдут все тесты. Изменения объединяются вверх по течению, и все счастливы.

Запуск всех тестов в первом сценарии также возможен, но тогда он такой же, как если бы у вас был один репозиторий, поскольку вы должны были оформить весь код.

Это моя точка зрения. Может быть, у вас есть большие активы в репо, которые вы не хотите, чтобы все проверяли, потому что они занимают 2 ГБ. Возможно, ваша кодовая база настолько велика, что перегрев не имеет значения.

Но я считаю, что, если вы не Google, IBM, ... накладные расходы, которые вы будете платить за управление несколькими репозиториями, будут слишком большими и лишат вас времени, которое вы могли бы потратить на более продуктивные вещи.

Ура, zimbatm