Георг Гаал

> В идеале было бы если бы разрабочтик в manual джобе мог бы указать какие версии деплоить, но я не нашёл как это сделать в Gitlab CI.

В самой мануальной джобе НИЧЕГО задавать нельзя. Но есть два варианта выкрутиться:

1. задавать переменные при инстанцировании пайплайна



2. сделать интерфейс, через который можно будет триггерить создание пайплайна / джобы по API со всеми нужными переменными - например, при помощи Rundeck

1. можно в самом пайплайне при помощи переменных или прямого обращения к git - определять какая ветка и выполнять конкретное действие. Проблема только лишь в том, что это не очень наглядно. И такой скрипт может быть с наскока сложно написать
2. Использовать расширенный синтаксис gitlab:
https://docs.gitlab.com/ee/ci/yaml/#rules или https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-advanced

Это плохая идея, т.к. у вас каждый последующий коммит зависит от предыдущего. И у всех коммитов после схлопывания изменится sha.
Коллеги уже выше дали информацию как пользоваться командой rebase для этой цели.
Это означает, что после "схлопывания" нужно будет всем пользователям репозитория у себя его полностью перекачать, а старые копии удалить.
Само по себе количество коммитов как правило не является лимитом или ограничением при работе с большим репозиторием. Есть ограничение по размеру в самом Гитлабе, но обычно его хватает за глаза для проекта любого разумного размера. А если у Вас монорепозиторий и он вылез за границы лимиты, то либо переезжаете на свой инстанс гитлаба, либо пора проект делить на модули, каждый в отдельном репозитории.

Ещё хочу добавить, что у git clone есть чудесный параметр depth, который позволяет ограничить глубину клонирования репозитория, если хочется сэкономить трафик и история с самого начала не нужна.

Из всех трех мне больше нравится ГитЛаб. Из-за общего набора возможностей и активного развития проекта. Возможны какие-то дополнительные требования - например, работа на стеке Атлассиан (JIRA+Confluence), тогда стоит присмотреться к битбакету (хотя в том же ГитЛабе достаточно вменяемая интеграция с JIRA)

ГитХаб исторически был лучше для опен-сурс проектов. И до сих пор часть вещей работают только с ним. Но если речь именно про приватные репозитории - Гитлаб интереснее будет.

Я не совсем понял вопроса.

Дело в том, что Gitlab-CI это не про это.
Он для каждого нового tag (при создании через веб-интерфейс или при пуше в репо) создает новый пайплайн. Вытащить tag можно либо через переменную CI_COMMIT_TAG или CI_COMMIT_REF_NAME / CI_COMMIT_REF_SLUG

Если же тэг хранится в репозитории в файле, то можно его из него и вытащить (голову репозитория надо рассказать как спуллить?).