Как управлять файлами конфигурации при совместной работе?

Question

Я пишу короткий скрипт с несколькими простыми переменными в верхней части страницы.Я хочу поработать над ними с другом, но мы не уверены, как управлять переменными, которые нужно менять после каждого извлечения одного из нас, добавляя ненужный мусор в состояние git.Я думал о том, чтобы просто создать разные именованные ветви для каждого из нас, и тогда мастер просто установит примерные имена пользователей, но кажется глупым делать всю эту дополнительную работу по слиянию.Мы могли бы передать переменные в сценарий в качестве параметров, но это нежелательно и не отделяло их в другой отдельный файл конфигурации.Было бы здорово иметь что-то вроде .gitignore, но игнорировать только несколько строк в файле.

Как это можно элегантно управлять?Как обычно решается эта проблема?

Answer 1

Боюсь, вы не можете просто проигнорировать изменения в определенных строках файла, так что вы, вероятно, застряли с отдельным файлом конфигурации.Ниже я перечислил два типичных способа решения этой проблемы и один немного более экзотический:

Иметь пример файла конфигурации в git

Здесь вы бы сохранили файл config.sample вgit в качестве примера, но приложение фактически использует значения в файле config, который находится в .gitignore.Приложение выдаст ошибку, если не указано config.Вы должны помнить об изменении значений в файле примера при добавлении новых переменных конфигурации в ваш личный файл config.В этом случае также неплохо бы, чтобы ваше приложение проверило, что все необходимые переменные конфигурации действительно установлены, в случае, если кто-то забыл обновить свой файл config после внесения изменений в образец.

Есть файлзначений по умолчанию в git

Вы сохраняете файл config.defaults в git, который имеет максимально допустимые значения конфигурации по умолчанию.Ваше приложение сначала получает конфигурацию из config.defaults, а затем из config (которая находится в .gitignore), чтобы, возможно, переопределить любое из значений по умолчанию.С помощью этого метода, как правило, вы не допустите ошибку, если config не существует, поэтому приложение может работать из коробки для людей, которые не удосужились создать config.

Использованиеодин файл конфигурации с параметром --assume-unchanged

Третья возможность, которую я не рекомендовал бы в этом случае лично, заключалась бы в том, чтобы иметь один файл конфигурации, который фиксируется в git, но использовать git update-index --assume-unchanged <FILE>, чтобы сказать git игнорировать изменения в нем.(Это описано далее в этом полезном сообщении в блоге .) Это означает, что ваши локальные изменения в файле конфигурации не будут зафиксированы с git commit -a или не отобразятся в git status.

Answer 2

Python / Django-специфичное решение состоит в том, чтобы иметь общие settings.py файлы, которые регистрируются в репозитории, и локальный settings_local.py, импортированный в конце settings.py, который переопределяет некоторые параметры с помощью машинно-специфичных значения.

Answer 3

В моем случае у меня есть переменные "config" в отдельном (маленьком) файле, как и все остальные разработчики в команде. Здесь хранятся такие вещи, как местоположение моей базы данных и т. Д. Мы поместили имя этого файла в наш .gitignore, чтобы он не контролировался версией, а зарегистрировался в файле «sample_config», чтобы новички могли сделать копию и использовать ее в своих целях.

Answer 4

Другие опции (не элегантно, но могут быть полезны):

• Используйте git stash и git stash pop для вашего конфигурационного файла
• Имейте ветку с именем, скажем, config , в котором изменения вашего локального файла конфигурации, а затем использовать git checkout config <your config file>

Второй вариант хорош, если вам нужно сохранить изменения локальной конфигурации в репозитории (где-то).

Answer 5

В настоящее время я использую переменные ENV, например, в python / django, вы также можете добавить к ним значения по умолчанию. В контексте docker я могу сохранить переменные ENV в файле docker-compose.yml или в дополнительном файле, который игнорируется в управлении версиями.

# settings.py
import os
DEBUG = os.getenv('DJANGO_DEBUG') == 'True'
EMAIL_HOST = os.environ.get('DJANGO_EMAIL_HOST', 'localhost')

Answer 6

У меня есть пара таких коротких скриптов, и вместо создания отдельного файла конфигурации я создаю отдельный файл setenv.sh (или setenv.bat). Я перемещаю несколько простых переменных в этот новый файл и вызываю файл setenv.sh в основном скрипте. Переменные, которые не будут меняться для каждого пользователя, остаются в основном скрипте. В зависимости от того, насколько мал этот скрипт setenv.sh, я либо напишу документацию о том, как создать этот setenv.sh, либо передам файл setenv.sh.sample для использования в качестве шаблона.

Вариантом этого является не создание или вызов setenv.sh, а предоставление пользователю возможности устанавливать переменные среды, используемые в основном скрипте. Основной скрипт будет жаловаться, если переменные не существуют.

Некоторые короткие сценарии превращаются в большие сценарии или становятся полноценными приложениями. Когда это происходит, я иду по пути файлов конфигурации. У нас есть приложение, которое управляет файлами конфигурации, которое называется Config, на http://www.configapp.com.. Config имеет концепцию сред и экземпляров. В вашем примере у вас есть 1 локальная среда и 2 экземпляра. Общие переменные входят в локальную среду, а переменные, специфичные для машины (вы и ваш друг), попадают в экземпляры. Это слишком много для небольших скриптов, но хорошо работает для приложений.