Работа с git в веб-проекте для нескольких клиентов

Есть ли лучшее предложение для веб-проектов управления версиями с небольшими случайными обновлениями в нескольких проектах клиентов с git?

Я хочу использовать git для управления версиями для веб-проектов. Основное отличие почти от всех других предложений заключается в том, что это веб-проект с использованием HTML, JavaScript и некоторых файлов PHP - никаких центральных библиотек, используемых одной или несколькими программами, как обычно в типичных пакетах Linux.

Все мои разные веб-проекты предназначены для разных клиентов на основе одних и тех же файлов платформы, я бы оценил, что 80% файлов идентичны (назовите их платформой), а 20% изменены для разных клиентов, чтобы они соответствовали их потребностям. Проблема здесь в том, что я не знаю, для каких файлов требуется обновление клиента - подробно каждый клиент отличается.

Лучше всего было бы поддерживать файлы определенной платформы в одном каталоге и накладывать эти файлы на определенные пользователем файлы в другой каталог. Чтобы решить эту проблему с помощью git, я пока не нашел ничего хорошего:

git подмодуль (например, предлагаемый здесь) как правило, предназначенные для того, чтобы источники поставщика разработали библиотеку, близкую к программе, которая связывает ее. Поэтому проблема заключается в том, что файлы платформ и клиентов находятся в разных каталогах, поэтому мне приходится смешивать их во время развертывания, чтобы создавать файлы для веб-сервера. Кроме того, мне нужно вручную синхронизировать деревья каталогов, и это будет очень много работать с 10 иерархиями иерархии каталогов. В целом много сообщений ропщут о больших административных усилиях с использованием подмодулей, похоже, что это перебор.
git поддерево (например, предлагаемый здесь) кажется, проще, чем подмодуль, но страдает от одной и той же проблемы с разными каталогами, поэтому мне также необходимо синхронизировать структуру dir и смешивать файлы во время развертывания. Кроме того, трудно вернуть изменения платформы из репо клиента.
GitSlave (например, предлагаемый здесь) Я не уверен, что это может принести мне пользу. Это позволяет сохранять несколько репозиций git в синхронизации, возможно, это помогает синхронизировать структуру dir платформы, но я не могу поверить в это.
Рефакторинг между файлами платформы и клиента в разных каталогах (например, результат этого обсуждения) Я думаю, что это просто невозможно в случае моих клиентов и технологии, используемой веб-проектами. Для одного клиента этой странице требуется обновление, для другой этой страницы. Даже при введении PHP-структуры пользовательские изменения клиента распространяются по всему дереву.
Checkouts (например, также предлагаемый в этом обсуждении в последнем сообщении) Это выглядит очень просто и многообещающе с недостатком, что все клиентские файлы находятся вне git (поэтому вне контроля версий). Кроме того, если файл обновляется на платформе и в клиенте, тэг git не работает - он прерывается, поэтому это неприменимо
Филиалы поставщиков (например, перезапустили здесь) как я узнал, ветки сделаны для того, чтобы быть объединенными назад, и это не предназначено для моих клиентских патчей. Эти ветки всегда будут открыты, только сливаются после обновления с платформы (основной) по отношению к клиенту. И это приведет к мега-освещенной репо, сохраняющей всех клиентов и информацию о платформе, а не git способ обработки репозиториев.
Смешать во время развертывания. Таким образом, очень прагматичный метод хранения файлов платформы в одном репо и клиентских файлах также в специализированных репозиториях. Во время развертывания файлов на веб-сервере он может сначала записать все файлы платформы и перезаписать некоторые из них файлами определенной платформы. Смесь происходит очень поздно в каталоге веб-серверов. Это также имеет недостаток в том, что структуру каталогов каждого клиента необходимо вручную синхронизировать с структурой платформы - иначе развертывание будет слишком сложным.

Какой лучший подход здесь?

Ответ 1

TL; DR

Это проблема архитектурного проектирования, а не проблема управления исходным кодом. Тем не менее, это общая и интересная проблема, поэтому я предлагаю несколько общих советов о том, как решать ваши архитектурные проблемы.

Не действительно проблема Git

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

Рассмотрим эту цитату из Russ Olsen:

[Отдельно] вещи, которые могут измениться от вещей, которые, вероятно, останутся неизменными. Если вы можете определить, какие аспекты дизайна вашей системы могут измениться, вы можете выделить эти биты из более стабильных частей.

Olsen, Russ (2007-12-10). Шаблоны проектирования в Ruby (Kindle Locations 586-588). Pearson Education (США). Kindle Edition.

Некоторые предложения по рефакторингу

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

В каком-то конкретном порядке, вот что я лично сделал бы:

На уровне представления в значительной степени полагаться на шаблоны. Внимательно используйте макеты, включая или частичные, чтобы вы могли легче создавать объекты уровня представления.
Внимательно используйте конфигурационные файлы, специфичные для клиента (для этой цели я предпочитаю YAML), чтобы упростить настройку без изменения кода ядра.
На уровнях модели и контроллера выберите соответствующие структурные шаблоны чтобы позволить вашим объектам вести себя полиморфно на основе ваших конфигурационных файлов, специфичных для клиента. Duck-typing - ваш друг здесь!
Используйте некоторые интроспекции на основе имени хоста или домена, что позволяет полиморфное поведение для каждого клиента.

Следующие шаги с Git

После того как вы реорганизовали свое приложение, чтобы свести к минимуму изменения между клиентами, вы можете обнаружить, что вам даже не нужно отдельно хранить свой код, если вы не пытаетесь скрыть полиморфный код от каждого клиента. Если это так, вы можете, конечно, исследовать подмодули или отдельные ветки в этой точке, но без бремени тяжелого дублирования между ветвями.

Символы - это ваши друзья, тоже

Наконец, если вы обнаружите, что вы можете выделить изменения в несколько подкаталогов, Git поддерживает символические ссылки. Вы могли бы просто иметь весь свой разнообразный код в подкаталоге для каждого клиента в своей ветке разработки и символизировать файлы в нужные места в своих ветвях выпуска каждого клиента. Вы даже можете автоматизировать это с помощью некоторых сценариев оболочки или во время автоматических развертываний.

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