Евгений

В целом это умение приходит с опытом, прикидывайте сроки, работайте, смотрите насколько вы уложились или не уложились, анализируйте что пошло не так, как изменить дальнейшие оценки. Не забывайте закладывать всевозможные, технические и не только, риски в оценку.
В качестве юморной, но жизненной вставки, вот вам формула Бобука-Бацека https://www.youtube.com/watch?v=XUqiMEh2PMc

Видимо речь идет о создании сниппета

Если у вас многосайтовость с одним ядром, то держите все в одном репозитории.
Это избавит вас от ряда ненужных забот.
Если вы разойдетесь по разным репозитория, то получится, что у вас может быть задача например сделать фикс который затронет как общее "ядро" ( в init.php например что-то сделать) и при этом в конкретном сайте что-то добавить. И получится, что ради одной задачи вам надо делать 2 коммита в разные репозитории.
В истории таких изменений разобраться будет сложно. Да и работать так неудобно.

Судя по вашим рассуждениям вы выросли из этой компании. По описанным скиллам вы будете востребованным специалистом, ибо думающие программисты сейчас расходятся как горячие пирожки.
Из рассказа непонятно только как вы работая в студии, в команде не юзали гит? Эти знания подтяните, они вам обязательно потребуются. Но тут собственно ничего сложного и долгого нет.

Главное уважайте и цените себя. Если вы уже выросли из компании, и она вас пичкает говнозадачами, то не бойтесь делать решительный шаг. Под лежачий камень вода не течёт. Успехов.

Если вы все возитесь в одной папке для разработки, то у вас не только проблемы с CI\CD, но и в целом с культурой командной разработки.
Думаю вам можно начать со схемы попроще, чтобы люди в команде пообвыклись, поняли как улучшается коллективная разработка и потом уже на необходимый рабочий минимум вам нужно начать накручивать дополнительные фичи.
Только без лишнего оверхеда, ибо легко увлечься всеми современными трендовыми подходами для проекта, на котором оно не сильно надо.

Предложу вам необходимый на мой взгляд минимум:
1. проект загоняется под гит
2. каждому разработчику выделяется отдельный дев сервер, склонированный с прода (сильно желательно повторяющий окружение продакшена). Можно локально разворачивать вагранты, просто локально у себя проект поднимать, но мне больше нравится какой-то пак удаленных серверов для разработки, ибо часто разработчики сами не очень понимают как что правильно на сервере надо настроить и удаленный пак этих серверов может легко админить ваш сисадмин, а если у всех всё локально, да еще команда распределена географически - то это будет большое мучение и потеря времени
3. в мастере либо не работает вообще никто, либо там делают какие-то срочные хотфиксы. под каждую задачу выделяется отдельная ветка, в ней разрабатывается, и когда разработка протестирована и проверена - сливается в мастер
4. как смержили изменения в мастер - пуллите мастер на продакшене.
всё, это самый минимальный вариант, с чего надо начинать, чтобы люди привыкли. как только люди привыкнут и вы поймете что вашим разработчикам не хватает дисциплины и на прод в мастер коммитят что попало - делайте отдельную stage ветку и stage сервер. куда будете сливать наработки из веток-фич и проверять там за тем что
наразрабатывали. если изменения одобрены - stage вливайте в мастер и пулльте на продакшен.

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

Мне кажется уже этой схемы вам хватит надолго. А если и этого будет мало - можете продолжить плодить git-flow полный набор веток. Но для этого вы себе должны серьезно аргументировать их необходимость
Может быть для понимания CI\CD схемы на конкретном примере поможет такая статья antonov-dev.ru/blog/11
Там хоть и про битрикс, но общей идеи это не меняет особо