Как обмениваться настройками приложения между репозиториями

Question

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

Есть 2 РЕПО (не ветви):

• process = содержит специальную обработку данных с выходом в общую папку, доступную design
• design = веб-интерфейс , доступ к данным, обрабатываемым process

Есть 2 dev elopers:

• back-end developer = имеет доступ к process репо только
• front-end developer = имеет доступ к design репо только

Есть настройки программы для каждого из них. Некоторые настройки являются общими. Как путь к public folder. В действительности их больше, я просто хочу, чтобы это было просто.

Теперь back-end developer изменяет путь к public folder, совершает и толкать изменения в process репо. И моя проблема и вопрос: Как обновить путь до public folder в design репо?

До сих пор я мог найти лучшее, чтобы создать дополнительный репозиторий settings. Этот репозиторий затем добавляется как подмодуль к process и design. Поэтому, когда внешний разработчик запускает fetch или pull, путь обновляется. Однако мне не нравится добавлять новый репозиторий только для настроек, и мне было интересно, есть ли другой подход или концепция, которую я мог бы использовать.

Спасибо!

Answer 1

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