Хранение конфигов в Git’е

Немного замучился уже с конфигами. В общем ситуация, есть конфиги приложения, в них один файл общий для всех конфигураций и еще пара файлов уникальна для каждой конфигурации. Сейчас все файлы хранятся в одном репозитории, для создания новой конфигурации создается ветка, после завершения сливается с master. Таким образом master хранит все конфигурации и основной файл. Но проблемы вылазят когда нужно запушить изменения в основном файле из своей ветки в мастер, что бы другим конфигурациям были доступны изменения, вместе с ними в мастер пролазят «сырые» конфигурации, над которыми работал.

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

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

Теми: git, VCS, репозиторій

Ctrl + Enter

Andriy Neborak Embedded software developer в GlobalLogic 06.10.2016 13:46

Спасибо всем за ответ, сам капнул весь воркфлоу с этими конфигами и немного ужаснулся.
Понял, что мало дал информации, разрабатываем софт для железа. Файлы конфигов — это xml файлы, в одном содержится описание поддерживаемого функционала всех моделей выпущенных ранее устройств. Второй файл содержит перечень устройств, которые работают в одной установке. Оба файла необходимы для простенькой скады.
При разработке новой железки, добавляется ее описание в оба файла, в процессе работы какие-то данные могут менятся. Кроме того есть производство, которое берет эти файлы из нашего репозитория. И есть эксплуатанты, которые тоже получают доступ в случае удаленно обновления.
В этом все деле есть пара моментов:
1. разработку софта для железа делает комманда, но бывает так, что каждый человек делает железку для отдельной установки (отдельный файл), сейчас все файлы хранятся в одном репозитории, а разработка каждой установки ведется в отдельной ветке, но бывает, что устройство 1 делает работник А, устройство 2 делает работник Б, но в проекте у А есть устройство 2 тоже. На определеном этапе нужно обновлять файлы в репозиторий, что бы можно было получить чужие наработки.
2. Бывает так, что пересматривается подход к работе устройства и принимается решение изменить его функционал без обратной совместимости с уже работающими на объектах устройствах. Таким образом нельзя давать эксплуатации последнюю версию файла, она может уже не подходить к их конфигурации.
Пробую пока подмодули, вроде логично получается, основной файл как подмодуль. При коммите ветки сохраняется ревизия основного файла, если ветка старая и ее клонировать, то загрузится старая версия основного файла.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 01.10.2016 20:00

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

В виде истории? Если да — лучше почистить ветку перед мержем (для конфигов, думаю, годится и слияние коммитов в один и forced push результата — это же не исходники; или создать для мержа отдельную ветку).
Если же в виде отдельных файлов — то стереть лишнее перед мержем.

Неизменённые файлы мержу пофиг. Только изменения участвуют в слиянии.

Igor Yatsenko 30.09.2016 11:59

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

В большинстве случаев все намного проще — есть default сonfig файл с помощю которого можно стартануть приложение.
Default config можно хранить в репозитории.

При этом в случае если нужно переопределить некоторые значение конфигурации — для этого создают env сonfig (dev, prod, test...) который НЕ хранят в репозитории. Они должны быть в .gitignore
Или же задаются через переменные окружения.

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

Костя Третяк 30.09.2016 12:43

При этом в случае если нужно переопределить некоторые значение конфигурации — для этого создают env сonfig (dev, prod, test...) который НЕ хранят в репозитории

На скільки я зрозумів, то репозиторій створено спеціально для конфіг-файлів, там немає нічого іншого.

Igor Yatsenko

undefined pointer 29.09.2016 23:43

мне как-то помог
.gitattributes с merge=ours

но там есть нюансы
stackoverflow

Vanya Yani Web Developer в Capgemini Engineering 29.09.2016 22:54

Использовать ветки для долговременно хранения различных версий файла — это ад. Ветки — только для поддержки dev/beta/stable каналов релизов. То есть это лишь различные состояния ПО во времени. Не путайте версии приложения с его конфигурациями разворачивания. А не то потом отгребёте адов ад.

Если хотите хранить конфигурации разворачивания в репозитории — пожалуйста. Текущий конфигурационный файл НЕ ХРАНИТЕ в репозитории. Добавляйте его в .gitignore! Копируйте необходимый файл лишь на время работы над определенной конфигурацией. Либо задавайте нужный файл с помощью переменной окружения при запуске.

Valentin Nechayev архімаггриб в Дарницькі печери 01.10.2016 19:50

Не путайте версии приложения с его конфигурациями разворачивания. А не то потом отгребёте адов ад.

Я так понял, у них это и так разные репы.

Текущий конфигурационный файл НЕ ХРАНИТЕ в репозитории. Добавляйте его в .gitignore!

С чего вдруг? (если конфиги — отдельно, но даже и без этого)

Либо задавайте нужный файл с помощью переменной окружения при запуске.

По-моему, никто не уточнял, что там за софт. Может, там и окружения нет в привычном стиле.

Vanya Yani

Костя Третяк 29.09.2016 20:34

На скільки я зрозумів, то для додаткових конфігів у вас є свій бранч, а для основного конфіга — немає, і саме через це виникають проблеми. Так чому б не створити окремий бранч і для основного конфіга?

Щоб «не пролазили сирі дані», для цього є команда git stash. Тобто, якщо в даний момент ви працюєте із додатковим конфігом і не завершили його, то робите

git stash

Ця команда зберігає в чорновики ваші останні зміни в поточному бранчі, причому робить це без коміту. Після цього ви можете перейти у гілку з основним конфігом, зробити там необхідні зміни, закомітити та злити їх із мастером.

Після чого повертаєтесь у свій бранч, де не завершили роботу і робите

git stash pop

Ця команда повертає на місце незавершені вами зміни... і всі задоволені.

Чи я щось сильно спростив?

Mykola Gurov тролль 29.09.2016 15:49

Может просто ваш git workflow подтюнить? Предосматривать изменения при пуше из рабочей ветки в мастер. Подправлять историю ветки (git rebase —interactive) перед тем как незавершенный бранч в мастер пушить. Может будет проще отслеживать эти изменения если разбить тот большой файл на более мелкие секции?

Еще вариант — вести две ветки вместо одной. В одной (А) только общие изменения, которые время от времени подмерживаются в мастер и обратно, а в другой (B) — только новые файлы, коммиты отсюда не попадают в мастер до самого конца, но идет постоянная синхронизация master->A->B. Возни с такой структурой побольше, но иногда оправданно.

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

Бразильская система 29.09.2016 14:47

git checkout может быть полезен.

См. пример “The Simplest Thing That Could Possibly Work” jasonrudolph.com/...iles-from-another-branch

Denis Loshkarev Специалист Информационные технологии и услуги 29.09.2016 13:19

Эммм, а я не понял, как насчет коммита только изменений основного файла? Как вариант, если были уже коммиты в новые конфиги с момента создания ветки. Можно быстро создать еще одну ветку от того же родителя и изменить там только основной конфиг. Или я что-то не понял?

Andriy Neborak Embedded software developer в GlobalLogic 29.09.2016 13:30

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

Denis Loshkarev

Roman Sereda Devops 29.09.2016 13:48

Вводите переенную окружения (сборки) и подгружайте ваши конфиги согласно значения переменной. А в конфиг файла все параметри или набор фалов/папок с параметрами котрие грузить для каждого из окружений
все в едином репозитории без пляски с разними бранчами.
Переменная указивается при разворачивании в env

Andriy Neborak

Vanya Yani Web Developer в Capgemini Engineering 29.09.2016 23:01

Первый трезвый комментарий.

Roman Sereda

Хранение конфигов в Git’е

Схожі топіки

14 коментарів

Підписатись на коментарі

Новини