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

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

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

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

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

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

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

14
задан Community 23 May 2017 в 12:34
поделиться