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

Ответ 1

Драйверы фильтров - это "автоматический" способ реализации опции 3, как указано в "когда у вас есть секретный ключ в вашем проекте, как можно нажать Возможно ли GitHub?":

smudge script будет при проверке:

• определить правильные файлы конфигурации для изменения
• выберите необходимую информацию (лучше всего сохранить вне любого Git repo) и заменит значения шаблона на фактический.

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

Ответ 2

То, как мы это делали в последнем проекте, над которым я работал, - это иметь главный файл конфигурации, который загружал локальный файл конфигурации пользователя, если он присутствовал, который мог бы перезаписать установленные по умолчанию значения в master, если он указан, и объявил его собственную конфигурационную информацию если нет в мастер. Локальный файл был добавлен в gitignore. Таким образом, все общие вещи могут быть разделены, а некоторые конфигурации всегда присутствуют, и каждый разработчик может изменять свои локальные.

Ответ 3

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

Мы начали использовать шифрование для конфиденциальных сведений в config: Обработка паролей в конфигурации производства для автоматического развертывания

В случае git вы можете посмотреть git attributes filter attribute для выполнения как замены локальных значений, так и дешифрования чувствительных значений в автоматическом режиме.

Вы также можете иметь подмодули, которые говорят production.yml и с ограниченным доступом к репозиторию подмодуля.

Ответ 4

Так как мне понадобилось некоторое время, чтобы найти рабочее решение с подсказками @VonC, вот полный пример того, как игнорировать пароли с чистым фильтром git в заголовочном файле Objective-C.

• Предположим, у вас есть конфигурация по умолчанию script с именем Config.h, содержащая этот

  // Change "12345" to your password
  #define kPass @"12345"
  #define kConstant 42
  

• Создайте script hidepass.sh, который соответствует критической строке и печатает строку по умолчанию вместо

  #!/bin/sh
  awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }'
  exit 0
  

• Сделайте исполняемый файл script и добавьте его в репо

• Скажите git, чтобы отфильтровать ваш файл конфигурации, добавив эту строку в .gitattributes (также добавьте .gitattributes к вашему репо)

  Config.h filter=hidepass
  

• Сообщите git использовать hidepass.sh script для скрытого фильтра во время очистки:

  git config filter.hidepass.clean ./hidepass.sh
  

Чтобы он теперь, вы можете изменить пароль в Config.h, но git не будет выполнять это изменение, потому что он всегда заменяет эту строку строкой по умолчанию на checkin.

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

Ответ 5

Одна вещь, о которой я могу думать, похожа на метод 2 и метод 1 выше. Где у вас есть каталог, в котором хранятся сложные вещи, уникальные для сайта, такие как каталоги для файлов конфигурации, загруженные пользователем файлы и т.д.

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

Например, скажем, у вас есть каталог "site_profile". В этом каталоге вы создаете файл с именем "README.settings.php" вместе с каталогом "файлы", который содержит загруженные пользователем файлы (как у администраторов, так и у интерфейсных пользователей). Все это находится под контролем версий.

Однако сайт будет запускать свои настройки с "settings.php", который здесь не будет. Но если вы переименуете "README.settings.php" в "settings.php", тогда у вас будет необходимый файл конфигурации (после того, как вы, конечно же, внесите свои пользовательские настройки).

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

Это то, что мы делаем с сайтами Drupal, где я работаю, и работает очень хорошо.

Ответ 6

В двух случаях вы упомянули:

• конфиденциальная информация (у каждого разработчика есть разные пароли БД и т.д.)

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

• информация о конкретной задаче (когда разработчик работает над определенной задачей, где нужно изменить некоторые настройки)

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

Ответ 7

Я сохранил свои локальные изменения конфигурации в stash git. Я использую git приложение stash вместо pop, так что я никогда не удаляю его из очереди stash. Таким образом, я могу использовать reset -hard, когда захочу.

Ответ 8

Не имея опыта работы с Git, но имея дело с теми же проблемами в других контекстах (Hibernate login creds в Spring JUnit suite, или ANT), для всего, что зависит от пользователя или зависит от локальная среда пользователя:

• У README перечислены эти зависимости и как настроить локальный env для запуска script.
• Замените эти зависимости в своем conf на вызовы системным свойствам или какой-то каркасный способ вывести внешние значения. Например, в ANT script вы можете заменить строки <sysproperty key="jdbc.username" value="${jdbc.username}"/>, где jdbc.username - системная переменная (которую вы можете установить в Eclipse).

Разработчики могут проверять все, что захотят, потому что conf является пользовательским агностиком.

Ответ 9

В список включено много хороших вариантов. Еще несколько вариантов:

• Добавить все конфиги в .gitignore. Затем создайте отдельный git проект с только файлами конфигурации. (Сохраните этот git # 2 в совершенно другой папке.) В этом git # 2 создайте несколько сценариев, похожих на apply-config /path/to/my_git1, save-config /path/to/my_git1, которые копируют или сохраняют файлы конфигурации для основного git Сделки рЕПО.
  • Я предпочитаю использовать подмодули. Я нашел работу с подмодулями громоздкими в большой команде.
  • Затем вы можете отслеживать конфигурации или использовать несколько репозиций git для таких вещей, как производственные настройки, настройки отладки, более оптимизированные настройки и т.д.
  • Использует один инструмент (GIT), который все понимают.
• Мне нравится идея поиска в домашней папке для чувствительных вещей, таких как информация о соединении с DB. (Упомянуто @avh)
• Для devOps вы можете рассмотреть такие вещи, как Ansible/Salt/Chef/Puppet для автоматизации развертываний и настроек.

Ответ 10

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