Хорошая структура github при работе со многими небольшими проектами, имеющими общую кодовую базу? - PullRequest
3 голосов
/ 25 февраля 2010

Я работаю в компании, занимающейся веб-разработкой, и мы думаем об использовании GitHub для контроля версий. Мы работаем с несколькими разными CMS-платформами на основе .NET и, конечно, с множеством разных клиентов.

У нас есть стандартная кодовая база для каждой CMS, с которой мы начинаем создавать новый сайт. Мы, конечно, хотели бы сохранить это и сделать возможным объединение некоторых изменений с разработанного сайта (когда стандартная кодовая база каким-то образом была улучшена).

Нам часто приходится вносить небольшие изменения в опубликованный сайт позднее, и мы хотели бы иметь возможность сделать это с минимальными усилиями (т.е. клиент с радостью платит нам, чтобы мы исправили его проблему в течение 2 часов, но не хочу заплатить за 2 часа, настроенный первым).

Как мы должны настроить это, чтобы иметь возможность работать эффективно? Я не очень привык распределять контроль версий (раньше я работал с CVS, Subversion и Clear Case), но по своему воображению мы могли:

  1. Настройте один репозиторий для каждого клиента, начните с копии стандартной базы кода и перейдите оттуда. Конечно, много репозиториев.
  2. Настройте один репозиторий для каждой CMS, а затем разветвьте одну ветку для каждого клиента. Вероятно, это (?) Лучший способ, но что произойдет, когда у нас будет 100 клиентов (= филиалов) в одном репозитории? Также не очень приятно, что мы создаем много веток, которые на самом деле не собирались сливаться с основной ветвью.

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

Спасибо за ваше время и помощь.

1 Ответ

2 голосов
/ 25 февраля 2010

С Git, несколько репозиториев имеют смысл для целей подмодулей (разделение общего компонента см. характер подмодулей Git , в третьей части ответа)

Но в вашем случае может работать один репо с филиалом на клиента, если вы используете филиалы для:

  • изолировать некоторые специфичные для клиента изменения (и с долгоживущей ветвью без слияния с master все в порядке),
  • при перебазировании тех же самых веток поверх мастера (который содержит общий код с общими эволюциями, необходимыми для всех ветвей).
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...