Предположим, у меня есть проект с их исходными файлами с версией.
Но в каждом выпуске может быть множество сценариев, очень специфичных для каждого.
Как файлы версий, предназначенные для выпуска
Например, с каждой версией я мог бы предоставить скрипт patch.sql для воздействия на материал базы данных.
Этот сценарий ОЧЕНЬ разный с каждым выпуском.
Как этот сценарий может быть версией?
Существует ли стратегия управления такими файлами?
Файлы, которые предназначены только для выпуска, а не для переноса, могут управляться точно так же, как и любой другой файл. Просто внесите необходимые изменения в файл и зафиксируйте их как обычно.
В противном случае, простой подход к миграции должны иметь каталоги как migration/v2_v3/, который содержит все патчи и сценарии, необходимую для перехода от версии 2 до версии 3.
Для конкретной темы миграции SQL, посмотри на Sqitch. Это управление версиями, контролирующее изменения SQL, поэтому вам не нужно придумывать собственную схему управления исправлениями SQL.
Если это специально для изменений базы данных между версиями, вы можете посмотреть, как [Rails обрабатывает миграцию] (http://guides.rubyonrails.org/migrations.html) для начальной точки. –
Возможно, вам понадобится процесс сборки. Процесс сборки может предварительно обработать sql-изменения в sql-скрипте. Но для этого вопроса трудно сказать, ищете ли вы решение git или инкрементную историю миграции sql. Процесс обновления миграции sql должен быть независимым от вашей системы управления версиями. Git просто хранит файлы с версиями - это не является неотъемлемой частью вашей проблемы с базой данных. – bryanmac
Например, я был частью больших команд и видел много подходов к миграции sql, но ни один из них не зависел от выбора для контроля источника ... – bryanmac