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

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

В настоящее время я использую 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, поэтому вы получите гораздо больше преимуществ, используя его в своем проекте.

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

Спасибо.

Похожий на квилт рабочий процесс

Это именно то, что раньше делалось с quilt, а сейчас вы делаете с Stacked Git (поверх Git ), Mercurial Queues (поверх Hg) или Loom (поверх Bazaar).

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

Чистый git

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

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

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

ветви

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

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

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

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

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

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

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

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

Мне кажется, вы говорите о разных вещах.

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

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

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

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