Сервис версионного контроля исходного кода и конфигураций
Сервис версионного контроля исходного кода и конфигураций (услуга 1.26) предоставляет следующие функции:
-
создание и ведение репозиториев исходного кода, конфигураций сред и конвейера Devops;
-
версионный контроль исходного кода и конфигураций с возможностью восстановления при использовании утилиты git;
-
управление правилами сохранения исходного кода для каждой команды за счет запрета на удаление веток;
-
создание запроса на внесение изменений в исходный код и веб-интерфейс для обсуждения предлагаемых изменений до их включения в официальный репозиторий проекта;
-
управление запросами на совместную верификацию и согласование изменений программного кода за счет использования запросов на слияние веток;
-
настройка правил и требований к запросам на изменение и слияние веток в репозитории (Pull Request):
- минимальное количество успешных сборок;
- минимальное количество согласующих запрос на слияние;
- аудит изменений в репозитории исходного кода;
-
указание связей запросов на слияние веток с объектами "история" и "дефект" за счет указания идентификатора объекта в Сервисах управления требованиями и управления дефектами соответственно;
-
разграничение прав доступа и аудит изменений;
-
связь с объектами управления требованиями, управления дефектами;
-
многопользовательский режим работы с репозиторием исходного кода или конфигураций.
Виды веток модели Git Flow
Можно выделить 2 типа веток:
- основные ветки (
masterиdevelop); - вспомогательные ветки (
release-*,bugfix/*иfeature/*) имеют ограниченный срок жизни и могут быть удалены после утраты актуальности.
Этапы разработки и соответствующие им модели
В цикле разработки большинства решений можно выделить фазы, когда ведется основная разработка, выполняется стабилизация перед релизом и поддержка выпущенного решения. Каждая из этих фаз использует различные типы веток и механизмы слияния изменений.
Активная разработка
В этой фазе участвует только одна основная ветка -
develop. Главная ветка (master) нужна только один раз, чтобы отвести от нее основную ветку разработки (develop).
В основном разработка идет в функциональных ветках (feature), по завершению которой изменения вливаются в ветку develop.Рассмотрим более подробно на примере:
Увеличить
Работа с локальными ветками Git
Убедитесь, что существует директория, в которую ранее был загружен удаленный git-репозиторий. Если такой директории нет, создайте ее. Для этого выполните команду:
git clone ${gitUrl} ${targetDir}
Создание локальной ветки от существующей удаленной
Для создания локальной ветки от уже существующей ветки выполните следующие действия:
-
Перейдите в директорию, в которую скопирован удаленный git-репозиторий, и подтяните последние изменения из Сервиса версионного контроля исходного кода и конфигураций. Для этого выполните команду:
cd ${targetDir} git fetch origin
Команда
git fetch origin извлекает все изменения, отправленные (push) на сервер origin. Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не изменяет то, над чем вы работаете в данный момент.-
Создайте локальную ветку, копию удаленной. Для этого выполните команду:
git checkout -b ${localBranchName} origin/${remoteBranchName}
Где:
gitUrl– ссылка для клонирования репозитория (http или ssh);targetDir– директория, в которую необходимо клонировать репозиторий;localBranchName– имя локальной ветки;remoteBranchName– имя удаленной ветки.
Синхронизация локальной ветки с удаленной
Для синхронизации веток в Git существует команда
git pull, но у нее есть один недостаток – создание коммита слияния в случае, если в локальной и удаленной ветках были изменения. Само слияние в большинстве случаев проходит в автоматическом режиме, однако история репозитория засоряется и становится менее полезной, особенно при активной разработке. Для решения этой проблемы рекомендуется применять интерактивное перестроение (rebase) при синхронизации.Использование интерактивного rebase вместо стандартного pull (fetch + merge) имеет ряд преимуществ:
- история изменений в ветках становится более читаемой и наглядной;
- появляется возможность изменять, объединять и удалять группы коммитов, которые были сделаны в локальной ветке.
Работа с метками
Основное назначение меток (
tag) – обозначение ключевых коммитов в репозитории. Таковыми, например, являются коммиты объединения ветки релиза и главной ветки (master), которые выполняются по завершению релиза.
Для создания метки коммита выполните команды:git tag -a ${tagName} ${gitCommit} -m "${tagComment}" git push origin ${tagName}
Где:
tagName– имя метки, например 'v1.0.0';gitCommit– sha1-хеш коммита для которого мы хотим создать метку;tagComment– комментарий к метке.
Проставление меток дает возможность легко найти и создать ветку для экстренного исправления, сравнить изменения, сделанные между релизами, или получить срез кода, соответствующего какому-либо из релизов.
Все созданные метки можно посмотреть, выполнив команду
git tag или через веб-интерфейс на вкладке "Tags".Минимальная конфигурация Сервиса обеспечивает:
- таймаут на формирование HTTP-запроса со стороны клиента после установления соединения (параметр
timeout http-request) — 120 секунд; - таймаут на установление соединения с сервером Gitlab — 10 секунд;
- таймаут на ожидание ответа от сервера Gitlab (параметр
timeout server) — 3 минуты; - максимальное количество соединений (параметр
maxconn, определяет максимально возможное количество соединений со стороны Потребителей, суммарный показатель по всем сервисам Works) — не более 50 000. Может уменьшаться в зависимости от ресурсов, потребляемых соединениями со стороны Потребителя.