Хранение конфигов в Git’е
Немного замучился уже с конфигами. В общем ситуация, есть конфиги приложения, в них один файл общий для всех конфигураций и еще пара файлов уникальна для каждой конфигурации. Сейчас все файлы хранятся в одном репозитории, для создания новой конфигурации создается ветка, после завершения сливается с master. Таким образом master хранит все конфигурации и основной файл. Но проблемы вылазят когда нужно запушить изменения в основном файле из своей ветки в мастер, что бы другим конфигурациям были доступны изменения, вместе с ними в мастер пролазят «сырые» конфигурации, над которыми работал.
Читал, что такая штука делается с помощью подмодулей, но иметь отдельных репозиторий для одного общего файла как из пушки по воробьям. Может кто подскажет как выкрутится?
В идеале было бы отлично если бы при создании ветки можно было извлечь из master только общий файл и создать в ней же пару файлов конфигурации, по завершении добавить их в master.
14 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівСпасибо всем за ответ, сам капнул весь воркфлоу с этими конфигами и немного ужаснулся.
Понял, что мало дал информации, разрабатываем софт для железа. Файлы конфигов — это xml файлы, в одном содержится описание поддерживаемого функционала всех моделей выпущенных ранее устройств. Второй файл содержит перечень устройств, которые работают в одной установке. Оба файла необходимы для простенькой скады.
При разработке новой железки, добавляется ее описание в оба файла, в процессе работы какие-то данные могут менятся. Кроме того есть производство, которое берет эти файлы из нашего репозитория. И есть эксплуатанты, которые тоже получают доступ в случае удаленно обновления.
В этом все деле есть пара моментов:
1. разработку софта для железа делает комманда, но бывает так, что каждый человек делает железку для отдельной установки (отдельный файл), сейчас все файлы хранятся в одном репозитории, а разработка каждой установки ведется в отдельной ветке, но бывает, что устройство 1 делает работник А, устройство 2 делает работник Б, но в проекте у А есть устройство 2 тоже. На определеном этапе нужно обновлять файлы в репозиторий, что бы можно было получить чужие наработки.
2. Бывает так, что пересматривается подход к работе устройства и принимается решение изменить его функционал без обратной совместимости с уже работающими на объектах устройствах. Таким образом нельзя давать эксплуатации последнюю версию файла, она может уже не подходить к их конфигурации.
Пробую пока подмодули, вроде логично получается, основной файл как подмодуль. При коммите ветки сохраняется ревизия основного файла, если ветка старая и ее клонировать, то загрузится старая версия основного файла.
В виде истории? Если да — лучше почистить ветку перед мержем (для конфигов, думаю, годится и слияние коммитов в один и forced push результата — это же не исходники; или создать для мержа отдельную ветку).
Если же в виде отдельных файлов — то стереть лишнее перед мержем.
Неизменённые файлы мержу пофиг. Только изменения участвуют в слиянии.
У вас каждый раз когда вы создаете новую ветку появляется новый конфиг файл?
В большинстве случаев все намного проще — есть default сonfig файл с помощю которого можно стартануть приложение.
Default config можно хранить в репозитории.
При этом в случае если нужно переопределить некоторые значение конфигурации — для этого создают env сonfig (dev, prod, test...) который НЕ хранят в репозитории. Они должны быть в .gitignore
Или же задаются через переменные окружения.
В случае если вы создали новую ветку для фичи и там требуется изменение конфигурации — то это нужно делать в default config file. Таким образом при мердже обратно в мастер не будет никаких проблем с файлами конфигураций.
На скільки я зрозумів, то репозиторій створено спеціально для конфіг-файлів, там немає нічого іншого.
мне как-то помог
.gitattributes с merge=ours
но там есть нюансы
stackoverflow
Использовать ветки для долговременно хранения различных версий файла — это ад. Ветки — только для поддержки dev/beta/stable каналов релизов. То есть это лишь различные состояния ПО во времени. Не путайте версии приложения с его конфигурациями разворачивания. А не то потом отгребёте адов ад.
Если хотите хранить конфигурации разворачивания в репозитории — пожалуйста. Текущий конфигурационный файл НЕ ХРАНИТЕ в репозитории. Добавляйте его в .gitignore! Копируйте необходимый файл лишь на время работы над определенной конфигурацией. Либо задавайте нужный файл с помощью переменной окружения при запуске.
Я так понял, у них это и так разные репы.
С чего вдруг? (если конфиги — отдельно, но даже и без этого)
По-моему, никто не уточнял, что там за софт. Может, там и окружения нет в привычном стиле.
На скільки я зрозумів, то для додаткових конфігів у вас є свій бранч, а для основного конфіга — немає, і саме через це виникають проблеми. Так чому б не створити окремий бранч і для основного конфіга?
Щоб «не пролазили сирі дані», для цього є команда git stash. Тобто, якщо в даний момент ви працюєте із додатковим конфігом і не завершили його, то робите
Ця команда зберігає в чорновики ваші останні зміни в поточному бранчі, причому робить це без коміту. Після цього ви можете перейти у гілку з основним конфігом, зробити там необхідні зміни, закомітити та злити їх із мастером.
Після чого повертаєтесь у свій бранч, де не завершили роботу і робите
Ця команда повертає на місце незавершені вами зміни... і всі задоволені.
Чи я щось сильно спростив?
Может просто ваш git workflow подтюнить? Предосматривать изменения при пуше из рабочей ветки в мастер. Подправлять историю ветки (git rebase —interactive) перед тем как незавершенный бранч в мастер пушить. Может будет проще отслеживать эти изменения если разбить тот большой файл на более мелкие секции?
Еще вариант — вести две ветки вместо одной. В одной (А) только общие изменения, которые время от времени подмерживаются в мастер и обратно, а в другой (B) — только новые файлы, коммиты отсюда не попадают в мастер до самого конца, но идет постоянная синхронизация master->A->B. Возни с такой структурой побольше, но иногда оправданно.
Вообще описанная проблема в общем случае не является чем-то специфичным именно для конфигурации. Похожая ситуация наблюдается в случае с долгоживущей фиче-веткой, в которую закрадываются рефактринги и почие изменения, которые желательно пораньше заинтегрировать в мастер.
git checkout может быть полезен.
См. пример “The Simplest Thing That Could Possibly Work” jasonrudolph.com/...
Эммм, а я не понял, как насчет коммита только изменений основного файла? Как вариант, если были уже коммиты в новые конфиги с момента создания ветки. Можно быстро создать еще одну ветку от того же родителя и изменить там только основной конфиг. Или я что-то не понял?
Вы все правильно поняли. Как вариант конечно, но тогда на каждую разработку будет пара веток, для синхронизации основного файла и файлов конфигурации.
Вводите переенную окружения (сборки) и подгружайте ваши конфиги согласно значения переменной. А в конфиг файла все параметри или набор фалов/папок с параметрами котрие грузить для каждого из окружений
все в едином репозитории без пляски с разними бранчами.
Переменная указивается при разворачивании в env
Первый трезвый комментарий.