GitLab — что это и как с ним работать через Git: clone, push, merge request, CI/CD

Git lab — это что такое

GitLab — это платформа, на которой хранятся Git-репозитории и вокруг которых строится командная работа: просмотр кода, merge request (запросы на слияние), задачи, вики, реестр контейнеров и встроенный CI/CD. Если коротко, git lab это «GitHub с собственным конвейером сборки и возможностью поставить всё у себя на сервере». Многие компании, особенно в России, держат код именно в GitLab, развёрнутом во внутренней сети.

Проект начинался в 2011 году как открытое приложение для хостинга кода, затем вокруг него выросла компания GitLab Inc. Платформа существует в двух вариантах: Community Edition — открытая версия, которую можно бесплатно установить на свой сервер, и Enterprise Edition с платными функциями. На облачном gitlab.com тарифы называются Free, Premium и Ultimate.

Важно не путать понятия. Git — это система контроля версий, программа на вашем компьютере. GitLab — сервис, который хранит удалённую копию репозитория и добавляет к ней интерфейс и инструменты для команды. Без Git с GitLab не поработать, а вот Git прекрасно живёт и без GitLab.

Git и GitLab: в чём разница

Запросы «git и gitlab что это» обычно задают, когда в вакансии или в первый рабочий день встречаются оба слова. Разница такая же, как между документом и облачным хранилищем: Git отслеживает изменения файлов, ведёт историю коммитов и ветки локально. GitLab принимает эту историю по сети и показывает её в браузере.

Все действия с кодом — commit, branch, merge — вы по-прежнему делаете в Git. GitLab лишь получает результат командой git push и позволяет обсудить его с коллегами.

GitLab и GitHub: чем отличаются

Оба сервиса хранят Git-репозитории и поддерживают ревью кода, поэтому базовые навыки переносятся один в один. Различия — в акцентах и в модели развёртывания.

На практике разработчик часто использует оба: личные проекты и портфолио — на GitHub, рабочий код — в корпоративном GitLab. Команды Git при этом одинаковы, меняется только адрес удалённого репозитория.

gitlab.com или свой сервер (self-hosted)

Облачный gitlab.com подходит для личных проектов и небольших команд: регистрируетесь и сразу создаёте репозитории. Обновления, резервные копии и доступность — забота GitLab. Ограничения бесплатного тарифа (число участников, минуты CI, объём хранилища) время от времени меняются, поэтому актуальные условия смотрите на странице тарифов.

Self-hosted GitLab компания ставит на свой сервер — из пакета для Linux, в Docker или в Kubernetes. Код не покидает внутреннюю сеть, можно подключить корпоративный вход через LDAP и настроить свои раннеры для сборки. Взамен администраторы сами отвечают за обновления и бэкапы. Для разработчика разница почти незаметна: адрес будет не gitlab.com, а, например, gitlab.company.ru.

Настройка Git для работы с GitLab

Перед первым коммитом укажите имя и e-mail — они попадут в историю, и GitLab по e-mail свяжет коммиты с вашим профилем:

git config --global user.name "Иван Петров"
git config --global user.email "ivan@example.com"

На Windows удобно работать в Git Bash: он ставится вместе с Git для Windows и содержит ssh-keygen, так что все команды из этой статьи работают в нём без изменений. Дальше нужно выбрать способ входа — HTTPS с токеном или SSH-ключ.

Вход по HTTPS: personal access token

Пароль от аккаунта для операций Git по HTTPS использовать не стоит, а при включённой двухфакторной аутентификации он и не сработает. Вместо него создайте personal access token в настройках профиля GitLab (раздел Access tokens). Для работы с кодом достаточно прав read_repository и write_repository; задайте срок действия и сразу сохраните токен — повторно его не покажут.

При первом push или clone Git спросит логин и пароль: введите имя пользователя GitLab, а вместо пароля — токен. Менеджер учётных данных (в Git для Windows он встроен) запомнит его, и вводить снова не придётся.

Вход по SSH-ключу

SSH удобнее для ежедневной работы: один раз добавили ключ — и больше ничего не вводите.

ssh-keygen -t ed25519 -C "ivan@example.com"
cat ~/.ssh/id_ed25519.pub

Содержимое файла .pub (публичный ключ) вставьте в настройках профиля GitLab в разделе SSH Keys. Проверка соединения:

ssh -T git@gitlab.com
Welcome to GitLab, @ivan.petrov!

Git clone GitLab: как склонировать репозиторий

На странице проекта есть кнопка Code с двумя адресами — для SSH и для HTTPS. Скопируйте нужный и выполните git clone:

# по HTTPS
git clone https://gitlab.com/my-group/my-project.git

# по SSH
git clone git@gitlab.com:my-group/my-project.git

В GitLab путь проекта может включать подгруппы, например gitlab.com/company/backend/api.git — это нормально, копируйте адрес целиком.

Git clone GitLab с токеном

В скриптах и на серверах, где некому ввести пароль, токен передают прямо в адресе. Логином может быть ваше имя пользователя или служебное oauth2:

git clone https://oauth2:ВАШ_ТОКЕН@gitlab.com/my-group/my-project.git

Учтите: такой адрес сохранится в .git/config и может попасть в историю команд оболочки. Для автоматизации лучше использовать deploy token или project access token с минимальными правами и ограниченным сроком, а в CI — встроенную переменную CI_JOB_TOKEN.

Git push в GitLab: отправить код

Если проект уже есть локально, создайте пустой проект в GitLab (без README, чтобы не было лишнего коммита) и привяжите удалённый репозиторий:

git remote add origin git@gitlab.com:my-group/my-project.git
git branch -M main
git push -u origin main

Флаг -u связывает локальную ветку с удалённой, после этого достаточно писать git push и git pull. Обычный цикл работы ничем не отличается от любого другого сервиса:

git switch -c feature/login
git add .
git commit -m "Добавить форму входа"
git push -u origin feature/login
git pull

Теги отправляются отдельно: git push origin v1.2.0 или все сразу через git push --tags. В GitLab теги видны в разделе Tags и часто запускают конвейер выпуска релиза.

Типичные ошибки git push в GitLab

• HTTP Basic: Access denied — неверный логин или вместо токена введён пароль. Создайте токен с правом write_repository и удалите старую запись из менеджера учётных данных.
• Permission denied (publickey) — GitLab не узнал SSH-ключ. Проверьте, что публичный ключ добавлен в профиль, и выполните ssh -T git@gitlab.com.
• You are not allowed to push code to protected branches — ветка (обычно main) защищена. Отправьте изменения в свою ветку и откройте merge request.
• rejected ... (fetch first) — на сервере есть коммиты, которых нет у вас. Выполните git pull --rebase и повторите push.
• remote: Project not found — опечатка в адресе или у вас нет доступа к проекту; уточните роль у владельца.

Merge request в GitLab

Merge request — аналог pull request на GitHub: просьба влить вашу ветку в основную. Именно в MR коллеги оставляют комментарии к строкам кода, запускаются проверки CI и принимается решение о слиянии. После push новой ветки GitLab выводит в терминале ссылку на создание MR, а в веб-интерфейсе появляется предложение его создать.

Создать MR можно и прямо из командной строки с помощью push options:

git push -o merge_request.create -o merge_request.target=main origin feature/login

Типичный процесс: ветка на задачу → коммиты → push → MR → ревью и зелёный конвейер → merge. При слиянии GitLab может объединить коммиты в один (squash) и удалить исходную ветку. Если в MR конфликт, проще всего обновить ветку локально — git pull --rebase origin main или git merge main, разрешить конфликты и снова сделать push.

Помечайте незаконченную работу как Draft: такой MR нельзя случайно влить, но коллеги уже видят изменения и могут их обсуждать.

CI/CD в GitLab: .gitlab-ci.yml

Главная особенность GitLab — встроенный CI/CD. Достаточно положить в корень репозитория файл .gitlab-ci.yml, и при каждом push GitLab запустит конвейер (pipeline) из этапов (stages) и задач (jobs). Задачи выполняют раннеры — на gitlab.com есть общие, на своём сервере их ставят отдельно.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG

Здесь тесты запускаются на каждый push, а задача deploy — только когда отправлен тег: git tag v1.0.0 и git push origin v1.0.0. Результаты конвейера видны прямо в merge request, и можно запретить слияние, пока проверки не прошли.

Как удалить репозиторий в GitLab

Команды Git удалить проект на сервере не умеют — git push только меняет ветки и теги. Удаляют проект в веб-интерфейсе: настройки проекта, раздел General, блок Advanced, кнопка удаления с подтверждением названия. Нужна роль Owner. Локальная копия при этом остаётся — это просто папка с .git.

Если нужно отвязать локальный репозиторий от GitLab, не удаляя ничего на сервере, достаточно git remote remove origin.

Когда выбирать GitLab

• Код нельзя выносить во внешнее облако — нужен свой сервер.
• Нужен CI/CD «из коробки» без сторонних сервисов.
• Большая организация с иерархией команд — пригодятся вложенные группы и гибкие роли.
• Вы устраиваетесь в компанию, где уже используют GitLab: тогда выбора нет, но навыки Git переносятся полностью.

Для портфолио и open source чаще выбирают GitHub: там больше сообщество и выше видимость проектов. Ничто не мешает держать проект в обоих сервисах — у репозитория может быть несколько remote.

Итог

GitLab — платформа для Git-репозиториев с ревью через merge request, задачами и встроенным CI/CD, доступная и в облаке, и на собственном сервере. Работа с ней сводится к знакомым командам: настройте вход по токену или SSH-ключу, затем clone, commit, push и merge request. Удалённые репозитории и командные workflow подробно разобраны на практике в курсе по Git.