Как правильно хранить файлы настроек в репозитории?

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

Да, просто дефолтный конфиг хранить в репе, а локальный менять как хочется. Естественно, по-хорошему надо бы иметь более приоритетный и менее приоритетный путь к конфигу. В опакеченном виде дефолт в итоге окажется в /etc, а если юзер захочет юзерский — скопирует файл к себе в ~/.config и изменит как хочет. Ну и ты для своихбайтомараний там же будешь развлекаться. Опционально, как вариант, программа может создавать там дефолтный конфиг при первом запуске, а юзер может его править как хочет.

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

Я бы отдельную репу сделал. Но вообще вот тут мне тоже интересно, кто как делает — может есть более элегантное решение.

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

Отлично, как-то не подумал об этом сначала.

До опакечивания еще далеко, даже не загадываю на это дело пока :)

более приоритетный и менее приоритетный путь к конфигу

Ещё можно делать fallback - embedded config с записью его в ~/.config/… если ни один конфиг не найден в ожидаемых местах.

Написать что-то типа config.example.cfg с какими-то умолчальными параметрами и хранить его в репе. Приложуха же пусть читает config.cfg. Главное не забывать поддерживать config.example.cfg в дефолтном состоянии.

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

https://git-lfs.com/ если это бинарники

Как правильно организовать их хранение? Отдельная репа для кода с тестами и эталонами?

отдельная репа, втыкать через сабмодуль.

Обычно я коммичу что-то вроде config.local.example. А в gitignore добавляю config.local. Разработчик должен после чекаута скопировать config.local.example в config.local и подправить что нужно под себя.

Кроме этого стараюсь делать так, чтобы и без config.local программа в каком-то виде запускалась и как-то работала. Не для всех проектов применимо, но обычно получается.

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

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

а зачем тебе хранить что-то личное в публичной репе?
в репе - шаблон с комментами, в тестовом пайплайне - +1 copy-операция, для тестовой среды.</trldr>

конфиг положи в файл name.conf.example или name.conf.default, а name.conf добавь в .gitignore

тестовые данные сложи в отдельную репу вместе с тестами если прям лишние, если не очень, то в эту же и сделай типа make test чтоб проверить сборку можно было

Закоммитить его с некими начальными параметрами

да, и потом не забыть в .gitignore добавить

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

Как правильно организовать их хранение? Отдельная репа для кода с тестами и эталонами?

Обычно тесты и данные для них лежат в той же репе в папке тест. Например, тесты xz https://github.com/tukaani-project/xz/tree/master/tests/files

.env в гитигнор, а sample.env в репозиторий кладешь