Разные файлы настроек в ветках git
Вопрос по git Есть две ветки master и develop В каждой ветке свой файл настроек для сайта, на master для продакшена, develop для тестового сайта. Как сделать так чтобы при merge файлы настроек сайта не передавались между ветками.
Ответы (2 шт):
Во-первых, рекомендуется не хранить файлы настроек в гите.
Во-вторых, что-то я сомневаюсь, что файлы настроек постоянно меняются. А если файлы не меняют, то и конфликтов между ними нет. По крайней мере, если они хоть раз были помёрджены.
Так что надо при ближайшем мёрдже просто выбрать нужную версию файла и всё. Ну или сделать мёрдж только с этим файлом с использованием -s ours.
Конфигурация тут привязана не к ветке, а к конкретной инсталляции системы или к конкретному окружению (ну там dev, QA, staging, prod). То есть, например, у вас можно тот же master развернуть на QA системе, или staging системе или на проде.
При этом в каждом случае нужна своя конфигурация, ведь каждая система использует свою БД и т.п.
Далее, что важно, версионность самого программного продукта и конфигураций разная. Что я имею ввиду. Версия продукта меняется, когда вносятся изменения в продукт, т.е. добавляется новый функционал или исправляются ошибки. И версия соотносится с комитом в системе контроля версий. Изменение, скажем, сервера БД (или пароля к БД), который используется на prod системе не должен влиять на версию продукта (а значит не должен порождать комиты в репозитории продукта).
Конфигурация же меняется по другим причинам: появилась новая staging система, переехали на другой сервер БД, сменили пароли в процедуре ротации паролей. Это происходит независимо от программного продукта.
Удобно хранить конфигурацию в системе контроля версий:
- есть история
- можно делать review через pull request-ы
- есть версионность самой конфигурации
Выход такой, что конфигурацию удобно хранить в отдельном репозитории. При этом конфигурацию для отдельных систем (типа QA, staging, prod) хранить в отдельных файлах или папках, а не ветках git.
При развертывании приложения имя конфигурации (это может быть имя QA, staging, prod) является параметром. Т.е. процедура развертывания принимает на вход:
- версию приложения
- версию конфигурации
- имя конфигурации
В простом случае версии могут неявно быть master, т.е. берем последнюю версию из master в обоих репозиториях.
И конечно все секреты (пароли, ключи) в репозитории с конфигурацией должны быть зашифрованы, а при развертывании нужно предоставить пароль/PGP-ключ для расшифровки.