Эффективная архитектура проекта с git - PullRequest
5 голосов
/ 13 января 2012

Во-первых, позвольте мне представить общую архитектуру проекта.

Это иерархическое. Мы разрабатываем серверное приложение для наших клиентов. Хранится на главном сервере .

Скажем, локальный сервер 1, локальный сервер 2, ..., локальный сервер n - это серверы (основные экземпляры приложений) в разных компаниях. У каждой компании есть один локальный сервер. В основном все локальные серверы имеют одинаковую функциональность (скажем, основной модуль), но каждая компания может иметь свой собственный . В качестве идеи было решено решить эту проблему с помощью git branching .

Давайте рассмотрим некоторые случаи.

Дело 1
Одна компания ( локальный сервер x ) хочет какую-то особую функцию, которая нужна только в этой компании. Следуя логике нашего представления о ветвях, мы делаем следующие шаги:

  1. создать ветку git на главном сервере
  2. разработка необходимых функций для этого сервера
  3. создать ветку git (ветку y) на локальном сервере x
  4. отправить изменения на главный сервер
  5. коммутатор y на локальном сервере x
  6. переключиться на главную ветку на главном сервере

Дело 2
Мы разработали некоторые функции (изменения в модуле ядра), которые являются общими для всех компаний

Дело 3
Мы разработали некоторые функции, которые являются общими для некоторых компаний

Хотите услышать ваши советы о том, как решить " Дело 2 " и " Дело 3 ".

Ответы [ 3 ]

8 голосов
/ 19 января 2012

Технически, @VonC правильно говорит, что ветки - это путь.

Хотя есть одна оговорка. Вы смешиваете две разные парадигмы здесь. SCM (git - инструмент) означает управление исходным кодом и его различными версиями.

Включение / отключение функций продукта - это управление продуктом. По сути, это сводится к разработке и развертыванию вашего приложения.

То, что вы пытаетесь сделать, - это объединить управление функциями вашего продукта с управлением версиями.

Это, безусловно, выполнимо (только через SCM), и, в зависимости от ваших требований, оно может действительно работать на вас.

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

Если я могу предложить, сохраните одну версию вашего приложения и внедрите механизм для включения / отключения «функций». Это сделает ваш SCM более понятным, понятным для внедрения и обслуживания.

Промежуточное звено должно иметь основную ветвь для основного модуля, а затем каждый подмодуль или функция является отдельной ветвью. Любой может установить основной модуль, и в соответствии с необходимостью / разрешением он может пойти и установить отдельные «функции» из своих соответствующих ветвей.

Надеюсь, это обеспечит некоторую ясность. Если у вас есть какие-либо вопросы, я с удовольствием их уточню.

2 голосов
/ 21 января 2012

Я в целом согласен с Mrchief.

Кроме того, я хотел бы отметить, что ветви git лучше всего использовать в одной из следующих трех ситуаций:

  • Разработка функции в отдельной ветвии объединить его с основной линией, когда все будет готово.
  • Сохранить старую версию с исправлениями ошибок или исправлениями безопасности
  • Вернуть функции порта текущей версии в более старую версию

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

1 голос
/ 16 января 2012

Тот факт, что мы говорим о базовом модуле с вариациями для клиентов, означает, что подмодули git здесь недопустимы:
Изменяется тот же набор файлов (либо для общей функции, вариант 2, либодля функций для некоторых клиентов, случай 3).

Таким образом, филиалы - хороший способ справиться с этим, за исключением того, что вам нужно управлять слияниями из одной ветви в несколько других." Как перемещать исправления между ветвями в DVCS? ".

...