Переспал со своими мыслями и понял, что гляжу на проблему совсем не под тем углом. Изложенный мной подход, отслеживание кода монолита, произрастает из опасений, что что-то или кто-то может изменить код и это останется незаметным. Но такая ситуация возможна только если нарушаются основополагающие принципы платформы и её модульности. Исходя из чего, я описал другой подход к разработке, который назвал - общепринятым.
Не знаю на сколько это соответствует действительности, и полноту выводов, но вот основные мысли.
Общепринятый подход к разработке сайта на OpenCart 3.
Ядро (платформа) и расширения неприкасаемы напрямую. Система установки расширений следит за этим строго. Поэтому следует максимально придерживаться этого правила. Для изменения кода используется система модификаторов. То есть конечное решение - это именно правильно собранная архитектура. Это фундамент - OC, и кирпичики - расширения и модификаторы, а также состояние БД (схемы и данных). В каком-то смысле стоит относится к готовым компонентам как скомпилированной версии кода с возможностью перегрузки кода, посредством модификаторов. Так может быть понятнее людям, пришедшим из мира компилируемых языков программирования.
Исходя из этого основополагающего принципа вытекают следующие выводы:
Отслеживать весь код не имеет смысла, так как он состоит из цельных элементов.
Следует выбирать расширения, которые не изменяют файлов, только через модификаторы. Ещё лучше когда расширение ставиться через систему расширений, которая держит это правило под контролем.
Контролю версий необходимо подвергать отдельные компоненты: расширения, модификаторы, темы, доработки самой платформы (своя сборка) - если ведётся их разработка.
Если требуется доработка какого-то компонента можно использовать Git. Тогда стоит производить свои изменения поверх кода. Например, при выходе новой версии темы удобно сделать ребейс своих изменений и решать конфликты. Либо если изменений немного сделать отдельный модификатор.
Для разработки нового компонента использовать контроль версий - Git.
При разработке собственных компонентов на среде разработки Dev можно использовать симлинки для подключения темы или расширения.
Апгрейд кода среды производится путём обновления компонентов одним из способов: заменой файлов или через переустановку используя менеджер расширений. Обновление платформы отдельная тема.
Апгрейд БД производится либо встроенным скриптом расширения, либо вручную.
Разработчикам решения для истории и справки следует вести документацию по процессу сборки и настройки приложения. Подойдёт wikki или просто markdown.
Если вам есть, чем дополнить этот список или возразить - милости просим! критика приветствуется.