Павел

У меня была похожая проблема. Суть была в том, что git при сохранении изменений и отправке их на GitHub некоторые файлы типа LF переделывал в CRLF. И я не понимал, почему проект в папке - в которой я его разворачивал и в которой работал с самого начала - нормально поднимается в Docker, а скаченный с репозитория(на другой комп например или на тот же но в другую папку) - нет.
Возможно поможет вот это - Что такое LF, CLRF и как с этим бороться?
Я же решил проблему добавив в корень проекта файл .gitattributes с таким содержимым:

docker-compose.yml text eol=lf
Dockerfile eol=lf
*.sh text eol=lf

А уже измененные файлы вернул из состояния CRLF в LF при помощи VS Code(в котором и работал)

dbdsgnr.appspot.com
https://dbdesigner.net/
https://www.draw.io/
https://erdplus.com/#/

В разных компаниях это делают по-разному. Процитирую свой старый ответ на эту же тему, но про Django.

Есть три способа:

1. Верстальщик делает для каждого типа страниц рыбу, бэкендер напяливает её на шаблонизатор. При дальнейших правках верстальщик правит рыбу, бэкендер правит шаблон. Плюс в простоте включения верстальщика в процесс, минус в дополнительной нагрузке на бэкендера. Хорошо подходит для привлечения верстальщиков со стороны.
   
2. Поднимаете отдельный сервер для разработки. Настраиваете на нём FTP. Запускаете на нём нужные проекты, выдаёте права только на шаблоны. Запускаете верстальщика по FTP с chroot'ом в каталоге с проектами. Минус - нужен дополнительный сервер и понимание языка шаблонизатора со стороны верстальщика. Плюс - снижение нагрузки на бэкендера и возможность тестировать правки на живом проекте.
   
3. На комп верстальщика ставится python и git. Верстальщик клонирует проект, запускает из корня проекта специально подготовленный батник, который активирует виртуальное окружение, ставит зависимости и запускает dev-сервер. Требует от верстальщика умения работать с git (а других нанимать и не надо), а от бэкендера делать нормальные приложения, которые не требуют долгих танцев с бубном для запуска.