Никогда не следует использовать docker exec для внесения изменений внутри контейнеров: эти изменения будут потеряны, как только контейнер выйдет и будет удален. docker exec - чрезвычайно полезный инструмент отладки, но он не должен быть частью вашего основного рабочего процесса Docker. (Например, он не отображается вообще в четырех шагах первой половины вашего вопроса.)
Для целей локальной разработки загрузка изображения в реестр на самом деле необязательна. Вы можете docker build изображение, затем сразу docker run его, не загружая его.
Если вы запустите docker-compose up, что именно произойдет, зависит от того, имеет ли файл docker-compose.yml build: или image: строк. Если есть и то и другое, то когда Compose создаст образ, он будет иметь указанные имя и тег, которые могут перекрываться с изображением в вашем реестре. Существующее изображение никогда не изменяется, но только одно изображение может иметь заданное имя и тег за раз, поэтому, если вы сделаете вручную docker-compose build, это может привести к тому, что предыдущее изображение будет скрыто (docker images покажет его с тегом <none>).
Если у вас есть локальные изменения и вы восстановили изображение, docker-compose up знает, как удалить и воссоздать существующий контейнер. Новый контейнер будет основан на новом изображении и будет иметь новый код. (Удаление и воссоздание контейнера таким способом является чрезвычайно обычным делом, и Compose также знает, как сделать это для множества других изменений конфигурации.)
Рабочий процесс, который в целом мне подходит, заключается в разработке данной службы. локально и получить его полностью пройдя свои собственные модульные тесты, без участия Docker. Как только вы дойдете до этого, , затем запустите docker-compose build, чтобы получить новый образ и провести интеграционное тестирование в вашей локальной среде. Если это удовлетворит вас, , тогда перейдите к управлению исходным кодом, и пусть ваша система непрерывной интеграции соберет и получит из этого sh образ
.