Перейти к содержанию
sv2109

Использование git при создании модулей.

Рекомендуемые сообщения

Кто-то использует git при создании модулей? Поделитесь опытом.

 

Интересует вопрос как все правильно организовать. Так как каждый модуль это:

 

1. разные версии

2. разные движки на котором этот модуль должен работать

 

У нас есть папка с модулем. Создаем в ней гит репозиторий. 

Имеем главную ветку в гите - мастер. Что здесь? Последняя версия модуля под последнюю версию движка?

Дальше ветки. Наверное правильно было бы для каждой версии движка создать отдельную ветку. То есть у нас будут ветки:

ocstore1541

ocstore1551

opencart1561 

итд. 

 

Дальше нужно как-то добавлять новый функционал. Как? Создать для этого например ветку features или develop? Добавлять все изменения в эту ветку после чего мержить с ветками версий движка? Для готовых версий модуля добавлять теги?

 

Но весь функционал нужно же тестировать на рабочем движке. Как быть? Просто копировать модуль c репозитория в папку с движком, проверять, если есть ошибки то исправлять их в репозитории, опять все копировать в папку движка опять проверять?.. долго..

Может можно как-то держать в репозитории также и движок и как-то обмениваться данными между этими репозиториями?

 

Я сейчас использую гит для самого движка для тестов. В главной ветке у меня чистый движок. Нужно протестировать какой-то модуль: создаю новую ветку, тестирую. В результате всегда под рукой 1 чистый движок. И не нужно устанавливать кучу копий одной версии движка. Очень удобно.

 

Короче, поделитесь опытом кто использует гит.

  • +1 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а зачем движек держать
я делаю так:
создается файл .gitignore в корне
 
ну и внем код в таком духе
 

*
!.gitignore
!/admin/
/admin/*
!/admin/controller/
/admin/controller/*
!/admin/controller/payment/
admin/controller/payment/*
!admin/controller/payment/modulename.php
!admin/language/
admin/language/*
!admin/language/russian/
admin/language/russian/*
!admin/language/russian/payment/
admin/language/russian/payment/*
!admin/language/russian/payment/modulename.php
!admin/view/
admin/view/*
!admin/view/template/
admin/view/template/*
!admin/view/template/payment/
admin/view/template/payment/*
!admin/view/template/payment/modulename.tpl

!/admin/model/
/admin/model/*
!/admin/model/payment/
/admin/model/payment/*
!/admin/model/payment/modulename.php

!/vqmod/
/vqmod/*
!/vqmod/xml/
/vqmod/xml/*
!/vqmod/xml/modulename.xml

!/catalog/
/catalog/*
!catalog/controller/
/catalog/controller/*
!catalog/controller/account/
/catalog/controller/account/*
!catalog/controller/account/modulename.php
!catalog/controller/payment/
/catalog/controller/payment/*
!catalog/controller/payment/modulename.php

!/catalog/language/
/catalog/language/*
!/catalog/language/russian/
/catalog/language/russian/*
!/catalog/language/russian/account/
/catalog/language/russian/account/*
!/catalog/language/russian/account/modulename.php
!/catalog/language/russian/payment/
/catalog/language/russian/payment/*
!/catalog/language/russian/payment/modulename.php

!/catalog/model/
/catalog/model/*
!/catalog/model/account/
/catalog/model/account/*
!/catalog/model/account/modulename.php
!/catalog/model/payment/
/catalog/model/payment/*
!/catalog/model/payment/modulename.php

!/catalog/view/
/catalog/view/*
!/catalog/view/theme/
/catalog/view/theme/*
!/catalog/view/theme/default/
/catalog/view/theme/default/*
!catalog/view/theme/default/template/
catalog/view/theme/default/template/*
!catalog/view/theme/default/template/account/
catalog/view/theme/default/template/account/*
!catalog/view/theme/default/template/account/modulename.tpl
!catalog/view/theme/default/template/payment/
catalog/view/theme/default/template/payment/*
!catalog/view/theme/default/template/payment/modulename.tpl

!/readme.txt
  • +1 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо.

То есть вы взяли движок, установили туда модуль, после чего в .gitignore добавили все файлы кроме файлов модуля. Правильно?

Но в таком случае нужно:

1. для каждого модуля держать отдельный движок, если модулей 2-3 это не проблема, а если модулей пару десятков?

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

3. ну и главное - не решается вопрос совместимости модуля и разных версий движка. Например на 1.5.4.1 модуль может работать, а на 1.5.5.1 нет. Что тогда? Устанавливать еще один движок для этого и создавать еще один репозиторий? Хорошо, установили, после этого добавили какую-то фичу в версию модуля для 1.5.4.1.. а как теперь ее перенести в 1.5.5.1 если это разные репозитории и никакой git merge не прокатит?

+ движков то много.. ocstore + opencart + иногда разные максисторы + у каждого движка куча версий..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вообщем гитигнор будет игнорить все что не вписано в него

 

1. это да

но тут есть дело например если несколько человек работает над модулем то это удобно

ничего лишнего нет

 

2. это неизбежно

я думал долго над этим но только видимо этот вариант

 

3. только ветки наверно спасут

 

если несовместимость то отдельная ветка

 

сам в поисках конечно универсального решения

но пока у меня такой вариант

 

в репе только файлы модуля

в мастере главная ветка самая высокая версия

далее в ветках для версий старых

Изменено пользователем ashap

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

тем более еще поправка

 

если держать файлы движка в репе то и базу надо тоже, а базу то никак и не засунуть

хотя чего то гдето есть как то можно и базу вроде

 

ну и развертованием базы из гита тоже будут опять таки танцы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3. только ветки наверно спасут

 

если несовместимость то отдельная ветка

ну так ветки тут как раз и не спасут. Потому что и нас модуль ведь установлен на движке 1.5.4.1, а протестировать его нужно на 1.5.5.1. Даже если мы создадим новую ветку, например "1551_hotfix" то движок, на котором установлен модуль то все равно остается 1.5.4.1.

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

сам в поисках конечно универсального решения

так поэтому я и создал тему чтобы как-то совместными усилиями найти какой-то универсальный варинат

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я просто разворачиваю на другом движке репозиторий и правлю модуль в новой ветке

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@sv2109, у меня всё, как в первом сообщении.

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

В репах для работы-отладки устанавливаются движки определённой версии. В мастере - чистая сборка. В ветках - отдельные модули.

Больной вопрос - как разрабатывать и фиксить модуль в одном репо (с дистрибутивом), а изменения коммитить-документировать в репо модуля. Пока не знаю хорошего решения. Но подумываю о том, чтобы просто сделать в модуле скрипт "установки" в папку с дистром, который будет делать симлинки на все файлы модуля.

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

В случае с другими модулями может будет сложнее, но вряд ли намного. Сохранить вывод `tree`, дописать там к полным путям `ln ...`, и скрипт готов. Мне кажется, это довольно удобно будет работать. Но ещё не пробовал.

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

В модуле обязательно сохраняю пары diff + папка со всеми изменёнными модулями. Это уже давно повелось. Разницу сохраняю готовым скриптом - см. http://rb.labtodo.com/page/kak-oblegchit-process-publikacii-izmenenij-na-server (первый раздел, про `git-extract`)

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Больной вопрос - как разрабатывать и фиксить модуль в одном репо (с дистрибутивом), а изменения коммитить-документировать в репо модуля.

Вот что мне вчера пришло в голову. Правда как это практически сделать еще нужно подумать:

 

Имеем 2 типа репозиториев:

1. Репозитории движка

2. Репозитории модулей

Репозитории движка:

имя: ocstore1551

ветки для модулей:

-модуль1

-модуль2

Репозитории модулей:

имя: модуль1

ветки для движков:

-ocstore1551

-ocstore1541

-opencart156

 

для того, чтобы добавить новую фичу в модуль:

- создаем новую ветку, например "feature1"

- вносит изменения

- мержим с ветками дистрибутивов например через cherry-pick чтобы забрать последний коммит а не всю ветку или мержить как-то в ручном режиме

- удаляем ветку "feature1"

Теперь самое интересное - проверка работы модуля на движке.

- добавляем к репозиторию модуля удаленный репозиторий движка:

git remote add ocstore1551 path

то есть добавляем удаленный репозиторий ocstore1551

- выгружаем изменения:

git push -u ocstore1551 ocstore1551:модуль1

то есть изменения из модуль1/1551 выгружаем в ocstore1551/модуль1 и делаем связь между ними

Это я пробовал, все работает. Единственно что эта команда выгрузки не всегда работала, не выгружало если ветка модуль1 была создана до этого. Если такой ветки нету, то при выгрузке она создавалась и после этого уже можно было в нее выгружать этой командой. Не знаю как выгрузить в уже созданную до этого ветку. Может какой-то опции не хватает.. Кто в курсе - подскажите.

Дальше:

- вносим изменения в ocstore1551/модуль1

- проверяем, коммитим

- забираем обратно в репозиторий модуля. Но тут нужно подумать как. Потому что нам не нужна вся ветка с файлами движка, нам нужны только изменения, фактически последний коммит. По идее должно работать что-то типа этого:

git pull opencart1551 4329204dad0c511244e5a11575caf3b8cf8e3f56

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

Как еще можно забрать последний коммит с удаленного репозитория? Нужно искать и пробовать. Кто в курсе?

Или вариант, который предложил ashap:

- добавить .gitignore в котором закрыть все файлы движка. Кстати, .gitignore он же может быть разным для каждой ветки (модуля). 

Тогда можно забирать не последний коммит, а всю ветку, при чем так как связь уже прописана, то будет просто:

git pull

и все изменения из opencart1551/модуль1 слиты в модуль1/opencart1551

 

Вот такой вариант. Вроде все логично и правильно:

- один репозиторий для модуля, один для движка, не нужно держать кучу движков для каждого модуля

- обмен происходит очень просто 2 командами: git push, git pull

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не вижу смысла через добавление репозитория и пушы-пуллы делать это всё. Мне, честно говоря, не верится, что пуш из репо с десятком файлов в репозиторий с полной копией движка (и эти репо никак не связаны между собой) пройдёт безболезненно. Да и смысла не вижу городить огород. Поясню.

Самые важные - это задачи установки, затем отладки / разработки модуля. Иметь модуль в виде, допускающим быстрое разворачивание - очень полезно. Всё ранее описанное прекрасно эту задачу решает. Модуль хранится и распространяется в двух видах: "файлы модуля без перезаписи + vQmod XML" - для обычных пользователей, и "копия всех изменённых файлов + diff" - для разработчиков и тех, кому надо внести изменения в сильно изменённый движок.

* Накатить модуль на любой движок/версию в целях проверки установки пользователем? Задача легко решается.

* Накатить модуль на движок в целях доработки? `git branch` в настроенном движке нужной нам версии, копирование и установка модуля, доработки. Обычно здесь присутствует 1-2 коммита. Их можно перенести в родной репозиторий модуля хоть вручную (извлекли разницу в виде изменённых файлов или взяли дифф последних 1-2 коммитов, накатили в репо модуля, сделали коммит "fix #123 подробное описание чего фиксили"), хоть через `git-format-patch` (получаем набор {1,2,3}.patch и храним их в репо модуля)

В общем-то всё. Все задачи разработки и дистрибуции модуля решаются. Фиксы и новые фичи переносить из репо `ocs1551` в репо `opencart-sv2109-megasuperpuper` нетрудно. Заодно с этим переносом логично решается задача оформления описания изменений в ридми. Может он и автоматом сгенерится из истории коммитов, а может и вручную куда допишется (в ридми, в описание на площадках, где модуль выставлен). И в этом поможет эта вот тарнзакция из вручную переносимого diff + изменившиеся файлы (или пачка из нескольких .patch файлов, копирующих коммиты). То есть одновременно этот перенос помогает задаче документирования изменений. Ведь там надо:

- задокументировать изменения в модуле для себя

- описать изменения в CHANGELOG для пользователей

- разослать обновление или уведомление об изменениях

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

Затронутая ещё одна тема, распространения и описания модуля, тоже заслуживает отдельного внимания. Можно и об этом поговорить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Как еще можно забрать последний коммит с удаленного репозитория? Нужно искать и пробовать. Кто в курсе?

Отвечу ещё раз конкретно на этот вопрос: я обычно делаю 2 команды

git log -p HEAD^.. > issue1234-fix-header-info.diff
и

git-extract HEAD^.. && mv .deployment issue1234-fix-header-info.CHANGED-FILES
Всё. И переносится один-два коммита в другой репо легко и просто. То ли через `git apply issue1234.diff`, то ли копированием файлов поверх и фиксацией коммита (в истории команд найти и нажать энтер). Если файлы модуля слинкованы из репо ocs1551 в репо модуля, то в репо с полной копией идёт чисто правка файлов (отладка) и тестирование в броузере, а коммиты делаются только в репо с файлами модуля. То есть в репо с копией движка - отпочковали ветку, скопировали модуль, исправили, пофиксили, проверили. Всё работает? Перешли в репо модуля и закоммитили изменения, т.к. все файлы изменялись здесь, а там только симлинки и рабочая копия, которую можно и нужно безболезненно грохнуть по окончании работы.

Либо же упоминавшийся неопробованный на практике вариант с `git format-patch ...` и переносом изменений через один или несколько .patch файлов.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не вижу смысла через добавление репозитория и пушы-пуллы делать это всё. Мне, честно говоря, не верится, что пуш из репо с десятком файлов в репозиторий с полной копией движка (и эти репо никак не связаны между собой) пройдёт безболезненно. Да и смысла не вижу городить огород.

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

По-моему намного проще подключить удаленный репозиторий (1 команда). После чего все обмены делать простыми git push, git pull. Никакого "огорода" я не вижу.

 

 

Проверил вариант обмена между репозиториями. 

 

0. организацию репозиториев я описал выше.

1. Репозиторий модуль1/ocstore1551 - добавляем удаленный репозиторий ocstore1551

git remote add ocstore1551 path

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

git config receive.denyCurrentBranch ignore

3. Репозиторий модуль1/ocstore1551 - добавляем .gitignore, как предложил ashap  только немного более универсальный вариант: сначала закрываем все и открываем только нужные каталоги - это стандартно для всех модулей и почти не меняется, после чего одной командой

"!/**/модуль1*"

открываем все файлы модуля. Обычно все файлы в модуле (контроллер, модель, представление, css, vqmod) называются одинаково. Если есть исключения, то для них добавить 1-2 строчки в .gitignore не проблема.

*

!.gitignore

!admin/

admin/*

!admin/controller/

admin/controller/*

!admin/controller/module/

admin/controller/module/*

!admin/language/

admin/language/*

!admin/language/russian/

admin/language/russian/*

!admin/language/russian/module/

admin/language/russian/module/*

!admin/language/english/

admin/language/english/*

!admin/language/english/module/

admin/language/english/module/*

!admin/view/

admin/view/*

!admin/view/template/

admin/view/template/*

!admin/view/template/module/

admin/view/template/module/*

!admin/model/

admin/model/*

!admin/model/module/

admin/model/module/*

!vqmod/

vqmod/*

!vqmod/xml/

vqmod/xml/*

!catalog/

catalog/*

!catalog/controller/

catalog/controller/*

!catalog/controller/module/

catalog/controller/module/*

!catalog/controller/catalog/

catalog/controller/catalog/*

!catalog/language/

catalog/language/*

!catalog/language/russian/

catalog/language/russian/*

!catalog/language/russian/module/

catalog/language/russian/module/*

!catalog/language/

catalog/language/*

!catalog/language/english/

catalog/language/english/*

!catalog/language/english/module/

catalog/language/english/module/*

!catalog/model/

catalog/model/*

!catalog/model/module/

catalog/model/module/*

!catalog/model/catalog/

catalog/model/catalog/*

!catalog/view/

catalog/view/*

!catalog/view/theme/

catalog/view/theme/*

!catalog/view/theme/default/

catalog/view/theme/default/*

!catalog/view/theme/default/template/

catalog/view/theme/default/template/*

!/**/модуль1*

 

4. Репозиторий модуль1/ocstore1551 - выгружаем все в ocstore1551/модуль1 за одно создаем новую ветку в ocstore1551/модуль1 и устанавливаем связь.

git push -u ocstore1551 ocstore1551:модуль1 

5. Все. Все настроено для работы. Теперь так как связь прописана, все изменения переносятся через git push, git pull без указаний репозитория и веток.

 

 

Один замеченный минус такого подхода - структура 2-х репозиториев должна быть одинаковой. А структура модуля немного отличается, так как в модуле есть также разные ридми и инструкции, а файлы для копирования у меня лежат в папке "upload". Как вариант можно вести все инструкции в отдельном репозитории. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Попробуй. И через пару месяцев или полгода вернёмся к обсуждению.

А я вот наоборот не понимаю какой смысл держать 2 репозитория и обмениваться данными между ними вручную через создание патчей

Потому что цель - именно получение этих разниц. Которые и рассылаются в обновлениях клиентам. В моей практике многие хотели именно список изменений, а не обновлённый модуль полностью.

Синхронизация двух репозиториев целью не является. В моём случае по крайней мере. И никаких дополнительных бонусов мне не приносит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати да, мне как покупателю порой удобней список изменений, ибо:

поставил модуль

сделал какието свои правки в движке магазина\модуля

вышло обновления модуля, но заливать новые файлы как то боязно, не хочется чтобы что-то сломалось)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Пользователи живых магазинов тоже всегда были в таком формате заинтересованы и переспрашивали - что конкретно изменилось в апдейте.

И чем более продавец практик (в отличие от собирателей модулей), тем важнее ему эта информация.

Так что это из опыта. Не только личного, но и клиентского - от заказчиков и покупателей.

Помню, @freelancer тоже когда-то писал, что обеими руками за это. Мы как-то обсуждали и хотели сделать это одним из пунктов требований к оформлению модулей и шаблонов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.