Системы контроля версий.

Добрый день. Кто-то использует в работе системы контроля версий? Как решаете вопрос с БД? Хотелось бы, так же услышать мнение разработчиков, вообще получится ли использовать такие системы в работе с Hostcms?

Разрабатываем (и даже переделываем/улучшаем старое) локально под Денвером
Было
Git + Bitbucket + бинарная синхронизация БД
Сейчас перешли на (удобнее при синхронизации нескольких разработчиков)
Git + Bitbucket + импорт/экспорт дампа БД

А импорт/экспорт дампа, как в ручную?

Цитата:

А импорт/экспорт дампа, как в ручную?

Нет, конечно же
Расскажу чуть подробнее, как у нас организовано.

1. Каждый новый проект создается на основе "болванки" - копии HostCMS Халява (версия поддерживается в актуальном состоянии), установленной под Денвером. Эта "болванка" является git-репозиторием от которого делается форк для нового проекта. Если планируется использовать платную версию HostCMS, то после форка повышаем его версию до платной.
   
2. С помощью .gitignore исключаем из репозитория все базы MySQL, кроме mysql\, performance_schema\ и phpmyadmin\
   
3. В корне репозитория имеется отдельная папка для хранения дампа
   
4. В репозитории "болванки" в отдельной папке лежат заранее подготовленные скрипты git-хуков:
   
   
   
   • pre-commit - создание в указанной выше папке дампов структуры и данных БД
     
   • prepare-commit-msg - добавляем в шаблон сообщения коммита, генерируемого git-ом, информацию об обновленных файлах дампа БД
     
   • post-merge - хук для "раскатывания" обновленного дампа, полученного при git pull в бинарном виде
     
   
   
5. После клонирования форка нового проекта на локальный диск один раз, вручную, запускается скрипт копирования хуков в \.git\hooks\
   
6. Имеются вспомогательные скрипты для импорта/экспорта БД из/в дамп
   
7. Имеются вспомогательные скрипты для запуска/остановки Денвера
   

Да, такой момент: ввиду компактного размера самого пакета Денвера, как вы могли догадаться, в "болванке", кроме развернутого ядра HostCMS Халява, хранятся файлы самого Денвера. Т.е. при клонировании проекта из удаленного репозитория все необходимые для работы файлы будут находится в склонированном репозитории.
Рабочий процесс выглядит примерно следующим образом:

1. Форк нового проекта
   
2. Клонирование на локальную машину
   
3. Установка git-хуков (скрипт)
   
4. Запуск Денвера (скрипт)
   
5. работа на сайтом
   
6. git commit
   При коммите хук синхронизирует дампы с бинарной БД
   
7. git push
   
8. git pull
   После вытягивания изменений из удаленного репозитория git будет пытаться автоматически смержевать дампы структуры и данных БД - в некоторых случаях это не всегда получается гладко, приходится мержевать "ручками".