2016-02-24 2 views
5

Я создаю приложение, которое будет работать с двумя отдельными версиями одного и того же программного обеспечения. Эти рамки будут иметь совершенно разные модули с общей зависимостью от созданной мной инфраструктуры JavaScript.Зависимость композитора от незначительных различий в файле composer.json

Скажем

dave/version1 
dave/version2 

Какие оба разделяют зависимость через требует от

dave/framework 

Я хочу сохранить эту структуру (DAVE/рамки) в одном хранилище, что оба родителя могут потребоваться модули. Однако местоположение, в котором эти файлы фреймов должны быть размещены, несколько отличается между этими двумя модулями, а также несколько разными требованиями к файлам composer.json, чтобы все правильно перемещалось (две версии этого программного обеспечения реализуют композитор по-разному).

С моим ограниченным знанием композитора и Git я сформулировал несколько решений:

  1. Создать три хранилищ, две оболочки репозиториев с конкретным composer.json файлами для поддержки каждых разных версий программного обеспечения. С другой зависимостью от третьего репозитория, который содержит фактическую структуру. Я не уверен, что это будет работать за пределами теории. Также в итоге становится немного грязным.

  2. Используйте некоторую форму умной маркировки и имеете версию 1 и версию2 в зависимости от отдельных версий фреймворка, которые, в свою очередь, будут иметь немного другой макияж. Композитор тогда боролся бы с вытаскиванием последней версии модуля, так как мы будем запускать две очень немного разные базы кода в странных версиях.

Однако оба эти кажутся потенциально грязными и неправильным способом структурирования того, что я пытаюсь достичь.

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

+0

Я считаю, что этот вопрос является дубликатом [Git ветвления для изменения нового продукта] (https://stackoverflow.com/q/15016201/1290731). Короче говоря, ваша первая идея - самый простой и самый гибкий и самый прямой способ сделать это, а также git. Вложенные репозитории называются «подмодулями», и есть команда, чтобы помочь с пререканием беспорядочных битов. Он сводится к установленному набору записей конфигурации по умолчанию, чтобы помочь клонировщикам и некоторым расфасованным ближайшим игрокам для общих задач. – jthill

ответ

1

При правильном планировании ваш первый вариант будет проще, чем вы думаете.

Git имеет систему, которая называется подмодули встроены прямо в.

Version1 и Version2 РЕПО будет включать в себя рамочные репо внутри них. Затем, когда вы обновляете Framework, вы можете вытащить эти обновления без проблем в версии 1/2. Вы контролируете, когда и как, так что вы можете следить за тем, чтобы вы не вводили ошибку по дороге.

Вот некоторые документы для подмодулей: https://git-scm.com/book/en/v2/Git-Tools-Submodules https://git-scm.com/docs/git-submodule

Смежные вопросы