вапринципе когда 100% клон это лучше чем 90% а 10% таскается из общего(родительского магазина/базы), но лучше в том случае если клон будет развиватся самостоятельно. Вообщем направление верное.
Тоже имеем опыт работы по такой схеме когда клиент имеет доступ к исходникам своего сайта, а поддержкой и развитием занимаемся мы, дико бесит когда клиент реализует своими средствами функционал причем в обход движка на котором сайт вертится и в итоге: конфликты с системным функционалом, никакого деплоя через CI, заливка доработок на сайт по фтп путем сверки каждого файла! (не дай бог перетрем функционал клиента), обновление composer пакетов ручками по фтп, и тд. А все потому что клиент требует доступ к своему сайту и все тут.
Максим Гречушников вы наверно меня не поняли, я согласен если обновление происходит разработчиком на локальном сайте, даже и через амдинку, но результат бага не так критичен, обновили -> протестили (ручками, автотесты) -> выкатили на рабочий если все ок.
НО, на рабочем сайте обновлять из админки, рискованно, не находите?
одно дело обновить модуль через компосер и накатить миграции, другое это протестировать систему с новой версией модуля, ведь может возникнуть ситуация что модуль может вызвать неработоспособность сайта из за конфликта с другими модулями, кривой миграции или кода, т.д. Что думаете по этому поводу?
как вариант создать ветку в гите feature/my-feature - чисто для кода feature/my-feature/data - миграции
если разработчику нужны миграции он сливает себе ветку с данными и устанавливает миграции
я использую схему разбиения пакетов по глобальному функционалу: CMS(базовый функционал, с установкой работает админка, публичка, модули: меню,слайдер и т.д.), eShop (интернет магаз, модули: витрина, каталог и т.д.), далее по такой же схеме могут быть Блог, Форум, Галерея и т.д
при установке все это дело находится в vendor, если в пакете находится ошибка я делаю коммит из пакета, так как при установке из компосера там находится репо гита, при комите создаю ветку что то вроде fix/any_bug и отправляю в репозиторий, то же самое с features. дальше кто отвечает за данный пакет уже принимает решения включать в релиз или нет.
не очень практика, мы щас ее используем)), дело в том что одно ядро на всех будет принудительно обновлять функционал для всех сайтов, и если кроме шаблонов в проекте разработан какой то модуль, расширен системный функционал или еще что то, то это при обновлении может вызвать сбой так как обновляя ядро вы должны учитывать индивидуальность каждого проекта, если проекты разрастутся следить за этим будет невозможно. Соответственно подтягивайте ядро для каждого сайта через компосер персонально, обновил, проверил, выкатил на сервер. Но если у вас один сайт и вы организуете что то вроде мультисайтовости то это уже другая тема.
как у нас было: site.ru/public/index.php, site.ru/vendor/company/core/src/Module/Menu/tpl/default.php, site.ru/public/Module/Menu/tpl/defaul.php
index.php - принимает все запросы подключает автолоадер и запускает ядро, ядро использует модули но при генерации шаблона используется принцип поиска аналогичного в каталоге проекта site.ru/vendor/core/src/Module/Menu/tpl/default.php, если он существует то будет подключен, в противном системный
с помощью mindmeister можно построить аналогичное