d-stream

Собственно вокруг любых систем контроля версий существуют и "системы сборки" - то есть как раз то что может по прописанному в репозитории что-то соберет и например отправит (на хосты/стенды или в хранилище артефактов).

Как пример - тот же gitlab и gitlab runners - то есть по коммиту/пендалю будет интерпретироваться .gitlab-ci.yml в котором могут быть прописаны нужные шаги (build, test, deploy и т.п.)

Ну или jenkins, по сути так же интерпретирующий jenkinsfile

Обычно инструкции по последовательности сборки-тестов-деплоя могут ветвиться в зависимости от того что за коммит или пул реквест и делать разное. К примеру при коммите в фичаветку - билд и тесты, при пулл реквесте - доппроверки, при успешном мерже в dev и успешной сборке - слив полученного в хранилище (а потом отдельной линией разлив этого из хранилища на тестовые стенды или прод)

p.s. по сути всё это повторяет ручные операции, если их хорошо описать aka автоматизирует
При желании это можно и навелосипедить, но задача типовая и поэтому есть 100500 решений почти от каждого крупняка... правда почти все они на начальном этапе несколько избыточны, но тем и хороши

Ну вообще хранить бинарники в системе контроля версий - ненормально. Поэтому верный путь состоит из нескольких направлений:
- чужие исходники - в отдельные репозитории
- бинарные артефакты - в хранилище артефактов (зависимостей)

Ну а в процессе сборки своего проекта - тянуть из первого и второго необходимые зависимости и из всего этого собирать то что будет деплоится на сервер.