Ответ 1

Используйте символические ссылки.

Возьмем пример, когда у вас есть файл конфигурации с именем "config.ini" . В рабочем каталоге вашего репозитория git вы должны сделать следующее:

• Создайте версию конфигурационного файла с именем "config-sample.ini". Это файл, в котором вы будете выполнять всю свою работу.

• Создайте символическую ссылку между "config.ini" и "config-sample.ini".

  ln -s config-sample.ini config.ini
  

  Это позволит всему вашему коду указывать на "config.ini" , даже если вы действительно поддерживаете "config-sample.ini".

• Обновите свой .gitignore, чтобы предотвратить сохранение "config.ini" . То есть, добавьте строку "config.ini" :

  echo "config.ini" >> .gitignore
  

• (Необязательно, но настоятельно рекомендуется) Создайте файл .gitattributes с линией "config.ini export-ignore".

  echo "config.ini export-ignore" >> .gitattributes
  

• Сделайте некоторые кодировки и разверните их....

• После развертывания вашего кода для производства скопируйте файл config-sample.ini на "config.ini" . Вам нужно будет внести какие-либо корректировки, необходимые для установки на производство. Это нужно сделать только при первом развертывании и при изменении структуры файла конфигурации.

Несколько преимуществ:

• Структура вашего файла конфигурации поддерживается в репо.

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

• Ваш "config-sample.ini" будет обновляться всякий раз, когда вы подталкиваете новую версию к выпуску. Это значительно облегчает поиск любых изменений, которые необходимо внести в ваш файл config.ini.

• Вы никогда не перезапишете производственную версию "config.ini" . (Необязательный шаг 4 с файлом .gitattributes добавляет дополнительную гарантию того, что вы никогда не экспортируете файл config.ini, даже если вы случайно добавите его в репо.)

(Это отлично работает для меня на Mac и Linux. Я предполагаю, что в Windows есть соответствующее решение, но кому-то придется прокомментировать это.)

Ответ 2

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

git add .

если вы хотите и не беспокоиться об этом.

Ответ 3

Лучший способ - создать файл с именем ".gitignore" и вставить файлы/папки, которые вы хотите игнорировать.

Таким образом вы можете сделать git add * everytime

Ответ 4

Доступны различные варианты:

1. Зафиксируйте конфигурационный файл по умолчанию, но разрешите локальный файл конфигурации

Добавьте файл default.conf в репозиторий Git.

Ваше приложение сначала ищет app.conf, но если оно не существует, оно использует default.conf.

Пользователи, которые хотят конфигурацию, отличную от настроек по умолчанию, могут скопировать default.conf в app.conf, а затем отредактировать ее.

Пользователи не должны передавать app.conf в репозиторий, потому что разные пользователи могут захотеть установить разные параметры в этом файле. (Поэтому вы должны положить app.conf в свой .gitignore.)

С закруткой (рекомендуется)

Ваше приложение всегда загружает default.conf, но если присутствует app.conf, он будет скопировать с app.conf по настройкам от default.conf.

Этот поворот имеет несколько преимуществ:

• app.conf нужно только удерживать различия от значений по умолчанию, делая их меньше и проще в обслуживании.

• При изменении приложения новые приложения по умолчанию, добавленные в default.conf, будут доступны для приложения, без необходимости копирования их в app.conf.

Это решение довольно похоже на ответ Алана У. Смита выше, с небольшой разницей: если приложение может начинаться без присутствующего файла app.conf, тогда он будет работать из коробки. Однако он добавляет некоторую сложность в код запуска приложения.

Предложение было одним из нескольких, сделанных Линусом Торвальдсом в списке рассылки Git или ядра, но я не смог найти его сегодня.

2. Использовать переменные среды и/или аргументы командной строки

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

CONFIG_FILE=test.conf ./start-app

или, альтернативно:

./start-app --config=test.conf

Это означает, что вы можете иметь несколько конфигурационных файлов development.conf, staging.conf и production.conf. Когда вы запустите приложение, вы скажете, какой файл конфигурации использовать.

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

Вы также можете использовать переменные окружения или аргументы командной строки для переопределения определенных параметров:

./start-app --config=default.conf --db-url=... --debug-level=5

3. Разные ветки

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

Откажитесь от разных ветвей для каждой вашей среды.

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

Когда ваша основная ветка обновляется, объединитесь из мастера в свои ветки.

Лично я не рекомендую этот подход. Я считаю, что это труднее поддерживать.