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

URL: https://skillaria.top/ru/guides/git/chto-takoe-gitlab

GitLab — это веб-платформа для хранения Git-репозиториев и совместной разработки: код, merge request, задачи и встроенный CI/CD в одном месте. Работать с ним можно на облачном gitlab.com или на собственном сервере компании, а сам код отправляется и забирается обычными командами Git — clone, push и pull.

## 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 принимает эту историю по сети и показывает её в браузере.

|  | Git | GitLab |
| --- | --- | --- |

| Что это | Программа контроля версий | Веб-платформа для репозиториев и командной работы |

| Где работает | На компьютере разработчика | На gitlab.com или на сервере компании |

| Нужен интернет | Нет, кроме push, pull, fetch, clone | Да, это сетевой сервис |

| Основное | Коммиты, ветки, слияния, история | Merge request, ревью, задачи, CI/CD, права доступа |

| Как с ним работают | Командная строка, IDE, GUI-клиенты | Браузер плюс обычные команды Git |

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

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

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

| Критерий | GitLab | GitHub |
| --- | --- | --- |

| Запрос на слияние | Merge request (MR) | Pull request (PR) |

| CI/CD | Встроенный GitLab CI/CD, файл `.gitlab-ci.yml` | GitHub Actions, файлы в `.github/workflows/` |

| Установка у себя | Бесплатная Community Edition на свой сервер | GitHub Enterprise Server, платно |

| Исходный код платформы | Открыт (Community Edition) | Закрыт |

| Группировка проектов | Группы и вложенные подгруппы | Организации |

| Где популярнее | Корпоративная разработка, внутренние серверы | Open source, публичные проекты, портфолио |

На практике разработчик часто использует оба: личные проекты и портфолио — на 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.

## FAQ

**GitLab бесплатный?**

Community Edition для установки на свой сервер бесплатна, на gitlab.com есть бесплатный тариф Free с ограничениями; расширенные функции доступны в платных тарифах Premium и Ultimate.

**Можно ли перенести проект с GitHub в GitLab?**

Да: в GitLab есть импорт проектов с GitHub, а историю можно перенести и вручную — git clone --mirror со старого адреса и git push --mirror на новый.

**Нужно ли учить отдельные команды для GitLab?**

Нет, с кодом вы работаете обычными командами Git; GitLab добавляет веб-интерфейс, а для автоматизации есть консольная утилита glab и API.

**Чем GitLab Flow отличается от Git Flow?**

GitLab Flow проще: работа идёт в feature-ветках с merge request в main, а для окружений и релизов при необходимости добавляются отдельные ветки, без develop и hotfix-веток Git Flow.


---
Source: Skillaria.Top (https://skillaria.top)