Если вы все возитесь в одной папке для разработки, то у вас не только проблемы с CI\CD, но и в целом с культурой командной разработки.
Думаю вам можно начать со схемы попроще, чтобы люди в команде пообвыклись, поняли как улучшается коллективная разработка и потом уже на необходимый рабочий минимум вам нужно начать накручивать дополнительные фичи.
Только без лишнего оверхеда, ибо легко увлечься всеми современными трендовыми подходами для проекта, на котором оно не сильно надо.
Предложу вам необходимый на мой взгляд минимум:
1. проект загоняется под гит
2. каждому разработчику выделяется отдельный дев сервер, склонированный с прода (сильно желательно повторяющий окружение продакшена). Можно локально разворачивать вагранты, просто локально у себя проект поднимать, но мне больше нравится какой-то пак удаленных серверов для разработки, ибо часто разработчики сами не очень понимают как что правильно на сервере надо настроить и удаленный пак этих серверов может легко админить ваш сисадмин, а если у всех всё локально, да еще команда распределена географически - то это будет большое мучение и потеря времени
3. в мастере либо не работает вообще никто, либо там делают какие-то срочные хотфиксы. под каждую задачу выделяется отдельная ветка, в ней разрабатывается, и когда разработка протестирована и проверена - сливается в мастер
4. как смержили изменения в мастер - пуллите мастер на продакшене.
всё, это самый минимальный вариант, с чего надо начинать, чтобы люди привыкли. как только люди привыкнут и вы поймете что вашим разработчикам не хватает дисциплины и на прод в мастер коммитят что попало - делайте отдельную stage ветку и stage сервер. куда будете сливать наработки из веток-фич и проверять там за тем что
наразрабатывали. если изменения одобрены - stage вливайте в мастер и пулльте на продакшен.
Когда поймете что устали ходить и руками пуллить на продакшене и запускать там всякие скрипты сборки фронтенда и прочее - можете пойти дальше. заводите отдельный сборочный сервер (он либо всегда висит статичный либо для каждой сборки можно развернуть например докер контейнер) на котором установлен весь софт необходимой для сборки. например все node-modules для сборки фронта.
И когда вы пушнули в мастер, то дженкинс или тимсити или еще что-то видит это, стягивает на сервер сборки ваш код, запускает все команды для сборки и после этого запаковывает собранный код. затем наступает время деплоя, когда деплойный скрипт переносит вашу сборку на продакшен, распаковывает ее и определенным образом делает ее активной, вместо той сборки, что была у вас (это может быть переключение симлинков, переключение докер-контейнеров и т.д.)
Мне кажется уже этой схемы вам хватит надолго. А если и этого будет мало - можете продолжить плодить git-flow полный набор веток. Но для этого вы себе должны серьезно аргументировать их необходимость
Может быть для понимания CI\CD схемы на конкретном примере поможет такая статья
antonov-dev.ru/blog/11
Там хоть и про битрикс, но общей идеи это не меняет особо
