Git и пароли

Да, обычно добавляют в .gitignore и кладут рядом config.example для будущих поколений.

не хранить пароли в исходниках

Хранить пароли в конфигурационных файлах приложения, а не в исходниках.

Я так и делаю. Но сам конфиг входит в проект (так что либо гитигнор, либо неизбежно попадание в репозиторий). Хотелось бы чтобы в репозитории он оставался дефолтным (от фреймворка).

Хранить в репозитории дефолтный конфиг. Реальный конфиг вынести за пределы репозитория в /etc/<ваше приложение>/config

Тогда придется ссылаться из проекта на конфиг который в /etc/<ваше приложение>/config. А перед пушем на гитхаб снова редактировать, чтобы оно ссылалось на дефолтный конфиг.

Хотя нет, в версиях всё сохранится же.

У тебя ctrl+s забиндено на коммит штоле?

сделай обертку для git commit, если тебя и такое не устраивает.

Файл с конфигом кидаешь в .gitignore, делаешь дефолтный конфиг и называешь его $config_name.conf.example, пишешь в ридми, что надо скопировать $config_name.conf.example в $config_name.conf или делаешь скрипт установки install.sh, который сделает всё за пользователя (если конфигов много).

тебе тяжко при запуске софта выставлять переменную или параметр которая говорит где брать конфиг?

Судя по тому что этот совет «прозвучал» тут дважды, буду считать что так обычно и делают. Спасибо.

Можно криптовать шареный Git репоситорий. Подробности гугляться.

Хотя я делаю так: если есть шареный бранч 'branch_name', то при чекауте на девелоп-машину, создается еще сополнительный бранч 'branch_name'.local, где все пароли есть, затем все мержится/ребэйзится в 'branch_name' (кроме паролей) и коммитится.

Можно еще поиграть с хуками и gnupg.

Ага, и хотелось более красивого решения.

красивее некуда - программа должна уметь менять свое поведение исходя из окружения запуска - так чтобы уметь запускать из ~/lib или /usr/lib

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

ТС не написал какой ЯП, поэтому предположил самый популярный.

<?php
/* local_config.php */
$blah_blah = 'real blah';
?>

<?php
/* config.php */
$blah_blah = 'stub blah';
if (file_exists('local_config.php')) {
  require_once 'local_config.php';
}
?>

красивое решение - хранить foobar.conf.defaults или foobar.conf.example в репозитории.

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

Если только пароли, то можно полениться и хранить в репозитории (хотя, паранойю никто не отменял).

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

+1

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

У нас сделано еще проще: две ветки, тест и продакшен, в тесте вся конфигурация тупо смешана с разработкой самого сайта, ветка с продакшеном хранит только изменения в конфигурации относительно теста. То есть, если в тесте настроена база данных X, то в мастере она заменяется на Y. Таким образом, изменения конфигурации в тесте автоматически сливаются с конфигурацией в продакшене и если мы, например, в тесте подключили плагин Z, то и в продакшене он окажется подключен, но настройки базы данных все равно будут Y, так как в продакшен ветке эти диффы уже есть. И, если в тесте настройки базы поменяются с X на P, то слияние с продакшеном зафейлится, и нужно будет вручную разрешать конфликт слияния, что в данном случае очень хорошо - не дает забыть о возможных изменениях в продуктивном конфиге. Кроме того, вся эта галиматья заставляет тебя сначала протестировать изменения, а потом спокойно сливать на боевой сервер.

для python делаю так:

файлы

app/settings
    settings.py
    settings_local.py
    __init__.py

__init__.py

from .settings import *
from .settings_local import *

в проекте, где собственно нужны настройки:

from app import settings

В settings.py лежат дефолтные несекретные настройки. После пулла новый разработчик делает touch setting_local.py и переопределяет все что нужно.

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

./start conf/васин_конфиг.xml

но опять же, это окружение разработчика, как оно деплоится я даже не знаю