Лучшие практики для использования Git с Magento? - PullRequest
Новая
       18

Лучшие практики для использования Git с Magento?

18 голосов
/ 30 декабря 2010

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

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

/app
  /code
     /community *
     /core
     /local *
  /design
     /adminhtml
     /frontend
        /base
        /yourtheme *
/lib
  /Zend
  /Varien
  /yourlib *
/js
  /yourjs *
  /varien
  /mage

Использование субмодуля git лучше всего работает в отдельных папках (например, / это ваше приложение, а / vendor / magento это субмодуль). Однако при такой степени переплетения подмодуль не выглядит хорошим решением. Я ошибаюсь по этому поводу?

Это оставляет меня с git поддеревом. Но с git поддеревом то же самое основное предположение (что ветвь вендора является, как следует из названия, поддеревом) не выполняется. Magento не поддерево, а основная библиотека, в которую помещается мой проект. Это правильно?

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

Последний вариант, который я не хочу использовать, - это репо, который я затем просто применяю к последним изменениям вендоров (извлеченным из архива). Я не хочу этого делать, так как чувствую, что наличие информации журнала поставщика (взятой из https://github.com/magentomirror/magento-mirror) было бы очень полезно для сортировки новых обновлений и выяснения, какие изменения повлияли на меня.

Ответы [ 5 ]

3 голосов
/ 02 марта 2012

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

3 голосов
/ 10 марта 2011

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

В настоящее время я использую 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 Installer - стоит посмотреть.

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

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

Спасибо.

1 голос
/ 21 июля 2011

Стеганый рабочий процесс

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

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

Pure Git

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

Rebase

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

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

Филиалы

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

1 голос
/ 10 июня 2011

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

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

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

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

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

1 голос
/ 23 января 2011

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

...