Имеем следующую ситуацию:
В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.
В чем проблема:
Возможные решения:
Как бы поступил я:
Если конфиг меняется крайне редко, то --assume-unchanged выглядит подходящим решением. Иначе просто не обращал бы внимания на изменения.
А вообще, надо хранить настройки отдельно.
В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.
В чем проблема:
- Этот файл должен находиться под версионным контролем, так как в нем содержатся «общие» настройки. Ну и сама структура файла ценна.
- Каждый разработчик меняет уровень логирования под свои нужды и не хочет, чтобы эти изменения попадали в коммиты, и тем более в интеграционный репозиторий.
- В этом файле периодически меняются общие настройки, и разработчик хочет их получать (pull) и публиковать (commit)
Возможные решения:
- Хранить исходные тексты приложения и его настройку отдельно. Но жизнь боль, и не всегда это можно сделать. Причины на это разные: от технических до (
некомпетентных людей) административных. - Пошаманить с загрузкой конфигурации. Например, под версионным контролем хранить default.super.config, а super.config исключить. Приложение должно сначала грузить свойства из default.super.config, а потом, если он есть, из super.config. Причем значения из последнего перекрывают значения из дефолтного.
- Просто не добавлять изменения локального конфига в индекс.
Плюсы:
- Простота.
- Если нужно закоммитить изменения в конфиге, то это делается по фрагментно (git add -p).
Минусы:
- Не сделаешь git add.
- Постоянно «маячат» какие-то изменения. Разработчик каждый раз их анализирует, проверяя все ли закоммитил.
- Переключение (checkout) на ветку с другим конфигом возможно только с ключом -m или через stash (ключ -f убивает изменения в рабочей копии).
- Pull изменений конфига приводит к ошибке. Прежде чем получить изменения, локальные придется убрать на полку.
Исключить конфиг из-под версионного контроля.
Не сработает. Только untracked файлы можно исключать из-под версионного контроля.
- Убедить git, что файл конфига не меняется. Как это сделать:
git update-index --assume-unchanged super.conf
Плюсы:
- git add . не добавит лишнего.
- «Чистый» статус.
Минусы:
- Git не сможет переключиться на ветку с другим конфигом, получить или закоммитить изменения конфига. При этом сообщения в консоли могут вводить в заблуждение: git status пишет «nothing to commit, working directory clean», а git pull — «Your local changes to the following files would…».
Для того чтобы разрешить эту ситуацию, придется открыть git глаза обратной командой git update-index --no-assume-unchanged super.conf. И все равно, далее придется воспользоваться полкой. - Посмотреть, на что git закрывает глаза можно командой git ls-files -v | grep -e "^[hsmrck]" (не, ну все же понятно).
Как бы поступил я:
Если конфиг меняется крайне редко, то --assume-unchanged выглядит подходящим решением. Иначе просто не обращал бы внимания на изменения.
А вообще, надо хранить настройки отдельно.
