bitrix and git

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

html/bitrix/cache/
html/bitrix/managed_cache/
html/bitrix/stack_cache/
html/bitrix/php_interface/dbconn.php
html/bitrix/modules/serverfilelog*
html/bitrix/modules/updater.log
html/bitrix/modules/serverfileerrorlog.dat
html/bitrix/wizards/
html/bitrix/backup/

Папка html — корень сайта.

Выше перечислены файлы и папки Битрикса, которые в репозитарий класть незачем. Иногда, в зависимости от проекта, имеет смысл исключить также папку upload, или наоборот, включить wizards.

Файл dbconn.php исключен по двум причинам:

1) Безопасность: не стоит класть реквизиты базы данных в репозитарий;
2) Удобство: если разработчики работают со своей локальной базой, то файл у всех будет различаться. Рано или поздно кто-то по ошибке его закоммитит и возникнут проблемы.

Вместо dbconn.php в php_interface удобно добавить dbconn.sample.php — болванку, которую разработчики смогут использовать как пример dbconn.php при разворачивании проекта локально.

Остальные файлы (test.php, логи, локи и тому подобное) каждый добавляет уже по вкусу.

Я на партнерке показывал, какие у нас исключения для меркуриала:
.hgignore

/bitrix/activities/bitrix/
/bitrix/admin
/bitrix/cache
/bitrix/components/bitrix/
/bitrix/gadgets/bitrix
/bitrix/controller_log
/bitrix/image_uploader
/bitrix/images
/bitrix/js
/bitrix/managed_cache
/bitrix/stack_cache
/bitrix/modules
/bitrix/otp
/bitrix/sounds
/bitrix/template/
/bitrix/themes
/bitrix/tmp
/bitrix/tools
/bitrix/wizards/bitrix
/bitrix/[^/]*\.php$
/upload
/bitrix/php_interface

По сути, обновляемое ядро исключается из контроля версий.

извиняюсь что поднимаю старую тему а как вы учитываете состояние БД битрикса в общем и структуры инфоблоков в частности?

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

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

Сообщение для подписки на тему, сразу галку не узрел...

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

Андрей, спасибо!
Нашел ваш модуль, обязательно позже с ним познакомлюсь.

Можно попробовать отслеживать и код и id - если id не изменился, но изменился код - свойство то же самое. =)

Может быть попробовать собраться толпой и реализовать модуль миграций? В одиночку такое потянуть будет очень тяжело.

Двумя руками за!
Большое дело сделаем)

Надо определиться, что по сути надо учесть при миграции БД. Вот что с ходу пришло в голову:
1) настройки иблоков
2) св-ва иблоков
3) пользовательские св-ва (для юзеров, доп. св-ва разделов и тд)
4) св-ва заказов
5) почтовые события и шаблоны
6) настройки различных сервисов (формы, рассылки и тд)

Модули с собственными таблицами не учитываем, там уже есть все что нужно)

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

КОННЭЭЭЧНО, давайте отвалим дофига бабла битриксу и наделаем для него модулей, еще немного отвалим и еще наделаем!