Ответ 1

Я думаю, вы можете использовать инструмент modgit для этого: https://github.com/jreinke/modgit Вы сможете клонировать некоторые модули Magento с помощью команды clone modgit. Полный пример доступен здесь: http://www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/

Ответ 2

Не те методы, которые вы упомянули, действительно сработали для меня...

В настоящее время я использую pear для установки и управления обновлениями модулей ядра и сообщества и создания целых magento-структур в git хранилище со следующим файлом .gitignore:

# Dynamic data that doesn't need to be in the repo
/var/*
/media/*
/downloader/pearlib/cache/*
/downloader/pearlib/download/*
/app/etc/use_cache.ser
local.xml

и используя следующую команду оболочки для хранения пустых каталогов:

for i in $(find . -type d -regex ``./[^.].*'' -empty); do touch $i"/.gitignore"; done;

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

Я попытался запустить тему на форуме magento, но также не получил никаких ответов: http://www.magentocommerce.com/boards/viewthread/78976/

Обновление:

Установщик Magento Composer - стоит посмотреть.

Composer становится стандартным инструментом управления зависимостями для PHP, поэтому вы получите гораздо больше преимуществ, используя его в своем проекте.

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

Спасибо.

Ответ 3

Ваш вопрос скорее о git подмодуле против поддерева вообще. Я не могу придумать никаких особенностей Magento, которые повлияют на сравнение. Скорее всего, вы знаете стратегии слияния поддеревьев, которые я буду рекомендовать, но я не уверен, почему вам нужно объединиться на первом месте.

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

• Избегайте исправления кода поставщика.
• Если вы не можете. Прежде чем делать патч, подумайте о том, чтобы упаковать ваши изменения в специальный модуль Magento и поместить его в app/code/local.

Если ваша модификация касается кода PHP:

• Вы можете использовать ООП и минимизировать изменения только для определенных методов. Расширение соответствующих классов.
• Перезаписать соответствующий класс с помощью механизма конфигурации Magento в файле config.xml.
• Если предыдущее невозможно достигнуть - поместите свои изменения (исправленные классы) в app/code/local, то есть выше в order_path, чтобы ваш код был эффективно использован вместо кода поставщика.

Если ваша модификация касается phtml templating → используйте механизм макета Magento для замены поставщика phtml вашим. Правильная настройка дизайна потребует значительных модификаций и макета.

Если ваша модификация касается JS → снова, используйте макеты, чтобы связать код, размещенный в папках js или skin.

Ответ 4

Я думаю, вы говорите о разных вещах.

Yauhen предложения абсолютно правильны. Вы можете выполнить все это в git, и вам не нужны подмодули или поддеревья.

У меня примерно такой же .gitignore файл, как вы, так что выглядит хорошо.

Я сделал запись о том, как мы используем git в качестве команды для управления магазинами magento, возможно, вам это будет полезно:

Рекомендации по развертыванию Magento

Ответ 5

Рабочий процесс, подобный Quilt

Это именно то, что было сделано ранее с помощью одеяла, которое вы теперь делаете с Stacked Git (поверх Git), Mercurial Queues (вверху Hg) или Loom (на вершине Базара).

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

Pure Git

Далее рассматривается клонирование Magento Git repo. Если они не используют Git, вы все равно можете сделать это, сначала переведя свою историю в Git, например, tailor.

Rebase

Git упрощает повторное применение части истории с другой отправной точки, rebasing. Таким образом, вы можете просто клонировать Magento, работать с вашим кодом и, обновляя Magento, делать это с последней чистой версии Magento, а затем перезаряжать вашу работу над новой чистой версией Magento.

В основном вы выполняете рабочий процесс Quilt с помощью обычных инструментов Git.

Филиалы

Еще один способ сделать это - просто использовать ветки. Вы клонируете Magento repo, отделитесь от него, сделайте свое дело, и когда вы получите последние изменения Magento, вы объедините две ветки. Это просто типичный рабочий процесс DVCS, рассматривая вас как разработчика Magento, работающего над ветвью функций, которая никогда не попадет в основную ветвь...