Git и GitLab

1. Что такое Git и GitLab

Git — это распределённая система контроля версий. Она записывает историю изменений файлов, позволяет возвращаться к любой версии и работать над проектом нескольким разработчикам одновременно.

GitLab — это веб-платформа для хостинга Git-репозиториев и организации работы команды. В отличие от Git (локального инструмента командной строки), GitLab работает на сервере и добавляет поверх Git графический интерфейс, трекер задач и систему непрерывной интеграции.

Для разработчика Git обязателен: он хранит историю, позволяет экспериментировать в отдельных ветках и откатывать неудачные изменения.

2. Установка Git

Скачай установщик для своей операционной системы с официального сайта git-scm.com и установи его с параметрами по умолчанию.

Проверь, что Git установлен и работает:

git --version
# git version 2.43.0.windows.1

Сразу после установки настрой имя и почту — они подписывают каждый твой коммит:

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

3. Основные команды Git

Команды выполняются в папке проекта. Создай репозиторий и сделай первый коммит:

git init
git status
git add .

git init создаёт скрытую папку .git — «базу данных» истории. git status показывает состояние файлов, а git add . добавляет все изменения в индекс (staging area).

Закоммить изменения с осмысленным сообщением:

git add .
git commit -m "Добавить модуль входа пользователя"

git log --oneline
# 3f2a91c Добавить модуль входа пользователя

git log показывает историю коммитов. Флаг --oneline делает вывод компактным.

4. Работа с удалённым репозиторием в GitLab

Удалённый репозиторий (remote) — это копия проекта на сервере GitLab. Сначала создай пустой проект в GitLab, затем подключи его к локальному:

git remote add origin https://gitlab.com/user/my-project.git

git push -u origin main

Скачать изменения с сервера и получить копию проекта:

git pull
# берёт изменения из удалённого репозитория

git clone https://gitlab.com/user/my-project.git
# скачивает копию всего проекта в новую папку

5. Ветки в Git

Ветка (branch) — это отдельная линия разработки. Она изолирует твои изменения, пока они не готовы к объединению в основную.

git branch
# * main

git checkout -b feature/login
# создаёт и переключает на новую ветку

git branch
# * feature/login
#   main

Переключение между ветками современной командой git switch:

git switch main
git switch -c feature/search

Когда работа в ветке закончена, её объединяют в главную:

git switch main
git merge feature/login

Если во время слияния возникли ошибки, прерви его:

git merge --abort

6. Merge Request в GitLab

Merge Request (MR) — это запрос на слияние ветки в основную через веб-интерфейс GitLab. Он превращает слияние кода в прозрачный процесс с проверкой.

Как создать MR:

1. Запушь свою ветку: git push -u origin feature/login.
2. В GitLab нажми кнопку Create merge request.
3. Укажи целевую ветку (например, main), заголовок и описание изменения.
4. Назначь ревьюера из команды и создай MR.

Во время code review коллеги оставляют комментарии прямо к строкам кода, задают вопросы и просят исправить недочёты.

Когда замечания устранены, ревьюер ставит Approve (одобрение), после чего слияние становится доступно. Кнопка Merge объединяет ветку и закрывает MR.

7. Решение конфликтов

Конфликт возникает, когда две ветки изменяют одни и те же строки одного файла, и Git не может выбрать «правильную» версию автоматически.

Разрешить конфликт вручную можно прямо в редакторе. Git размечает спорные участки:

<<<<<<< HEAD
const price = 100;
=======
const price = 150;
>>>>>>> feature/new-price

• Содержимое между <<<<<<< HEAD и ======= — версия из текущей ветки.
• Содержимое ниже ======= до >>>>>>> — версия из вливаемой ветки.

Оставь нужную строку, удали маркеры и закоммить результат:

git add .
git commit -m "Разрешить конфликт в файле price.js"

GitLab предлагает и визуальное разрешение в веб-интерфейсе: каждой конфликтной строке можно выбрать «использовать свою», «их» или отредактировать вручную. После этого MR можно завершать обычным образом.

8. .gitignore и README

Файл .gitignore перечисляет файлы и папки, которые Git не должен отслеживать. Так в репозиторий не попадают временные, служебные и секретные файлы.

Пример для Python-проекта:

__pycache__/
*.py[cod]
*.egg-info/
.venv/
venv/
.env
.ipynb_checkpoints/
pytest_cache/
dist/
build/

• .env — секреты (пароли, ключи), их нельзя коммитить.
• venv/ и .venv/ — виртуальное окружение, оно восстанавливается командой.
• __pycache__/ — скомпилированные кэши Python.

README.md — визитная карточка проекта, с которой начинается знакомство каждого нового разработчика. Обычно там указывают название, описание, как установить, запустить и протестировать проект.

9. CI/CD в GitLab

CI/CD (Continuous Integration / Continuous Delivery) — автоматизация сборки, тестирования и развёртывания кода. GitLab имеет встроенный конвейер (pipeline) для этого.

Ключевые понятия:

• Pipeline — весь процесс автоматизации, запускаемый по событию (например, push в ветку).
• Stages — этапы, на которые разбит конвейер (test, deploy и другие).
• Jobs — отдельные задачи внутри этапа (например, «запустить юнит-тесты»).

Конфигурация лежит в файле .gitlab-ci.yml в корне проекта:

stages:
  - test
  - deploy

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

deploy:
  stage: deploy
  image: alpine
  script:
    - echo "Развёртывание на сервер"
  only:
    - main

Когда код запушен в main, GitLab автоматически прогоняет тесты, и только при их успехе происходит развёртывание.

10. GitLab Runner и обзор интерфейса

GitLab Runner — это отдельное приложение (агент), которое выполняет jobs из конвейера на своём компьютере. Сам GitLab планирует конвейер, а Runner — отвечает за реальное выполнение команд.

gitlab-runner register
# укажи URL GitLab, токен проекта и описание раннера

gitlab-runner run

Runner можно запустить на своём компьютере или в Docker, а для больших команд — поднять отдельный пул раннеров.

Кроме репозиториев и CI/CD, GitLab объединяет весь цикл разработки:

Так GitLab закрывает путь «от задачи до продакшена» в одном интерфейсе.

11. Полезные команды и лучшие практики

Отложить незавершённые изменения и вернуться к чистому рабочему дереву:

git stash
git stash pop
# вернуть отложенные изменения обратно

Отменить последний коммит, сохранив его изменения в рабочей папке:

git revert HEAD
# создаёт «обратный» коммит, безопасно для истории

Полностью удалить последний коммит из истории:

git reset --hard HEAD~1

Лучшие практики работы с Git:

• Делай коммиты по одному логическому изменению — маленькие и частые.
• Пиши осмысленные commit message: «Добавить валидацию формы» вместо «исправления».
• Перед началом работы обновляй ветку: git pull.
• Не коммить секреты, пароли и ключи — используй .gitignore.
• Работай над новой функцией в отдельной ветке и вливай через MR.

12. Теги, релизы и окружения

Тег git tag — именованная метка конкретного коммита. Так отмечают выпущенные версии: v1.0.0, v2.3.1.

git tag v1.0.0
git push origin v1.0.0

# удалить тег на сервере, если ошибся
git push origin --delete v1.0.0

На странице проекта Deployments → Releases тег превращается в готовый Release: описание изменений, прикреплённые файлы и название версии видны команде.

Environments — отдельные «среды» приложения (staging, production). Деплой каждой среды оформляют отдельным job:

deploy-staging:
  stage: deploy
  environment: staging
  script:
    - echo "Деплой на тест-стенд"
  only:
    - main

deploy-prod:
  stage: deploy
  environment:
    name: production
  script:
    - echo "Деплой на боевой сервер"
  only:
    - tags

13. Protected branches, секреты и безопасность

Protected branches защищают важные ветки: пушить в них напрямую могут только авторизованные разработчики. Настройка: Settings → Repository → Protected branches. Обычно защищают main, а изменения вливают только через Merge Request.

Секреты конвейера хранятся не в коде, а в Settings → CI/CD → Variables. В .gitlab-ci.yml они подставляются по имени:

deploy:
  stage: deploy
  script:
    - echo "Подключаюсь к серверу $SERVER_IP"
    - ssh user@$SERVER_IP "docker compose up -d"
  only:
    - main

В GitLab есть бесплатные проверки безопасности: Security → Security Dashboard — SAST (статический анализ), Secret Detection (поиск утёкших ключей) и Dependency Scanning (уязвимости зависимостей).

Итоговая схема безопасной работы:

• Ветка main защищена, прямые пуши запрещены.
• Все изменения — только через Merge Request с одобрением ревьюера (Approvals).
• Секреты — только переменные CI/CD с ограниченным доступом.
• Конвейер перед деплоем прогоняет тесты, SAST и Secret Detection.

14. Review Apps: предпросмотр Merge Request

Review Apps для каждого MR поднимают отдельное окружение — ревьюер и тестировщик смотрят живой интерфейс, а не только diff кода. Реализация основана на dynamic environments:

review-app:
  stage: deploy
  image: alpine
  script:
    - echo "Деплой MR $CI_MERGE_REQUEST_IID"
    - echo "URL: https://mr-$CI_MERGE_REQUEST_IID.example.com"
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID.example.com
    on_stop: stop-review-app
  only:
    - merge_requests

stop-review-app:
  stage: deploy
  script:
    - echo "Окружение остановлено"
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    action: stop
  when: manual
  only:
    - merge_requests

Встроенные переменные CI_MERGE_REQUEST_IID, CI_COMMIT_SHA идентифицируют MR и коммит, поэтому окружение уникально для каждого запроса.

15. Include и шаблоны конвейеров

Одинаковые этапы не нужно копировать в каждый проект. Ключевое слово include подключает общие конфиги из других репозиториев или файлов:

// .gitlab-ci.yml в проекте
include:
  - project: 'devops/ci-templates'
    file: '/templates/test.yml'
    ref: main
  - local: '/local-test.yml'

stages:
  - test
  - deploy

// /templates/test.yml
.unit:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

Скрытые заданные с постфиксом . (например .unit) не выполняются сами — их наследуют реальные jobs через extends.

tests:
  extends: .unit
  image: python:3.12

16. Сканеры безопасности в GitLab

Безопасность в GitLab подключена на уровне конвейера — готовые шаблоны запускают статический анализ прямо в пайплайне:

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

Результаты попадают в Security Dashboard проекта: критичные уязвимости блокируют слияние, на фоне — панель по всем репозиториям группы.

17. Кэширование и производительность пайплайна

Ускорить конвейер помогают кэш зависимостей и правильная оркестрация jobs:

test:
  cache:
    key: pip-$CI_COMMIT_REF_SLUG
    paths:
      - .cache/pip
  script:
    - pip install -r requirements.txt

structure-test-and-deploy:
  needs: ["unit-tests", "e2e-tests"]   # только после нужных
  script:
    - echo "Продолжаем"

• cache кэширует между запусками — зависимости не скачиваются заново;
• artifacts передают отчёты и сборки между стадиями;
• needs запускает зависимые jobs сразу после нужных, не ожидая всю стадию;
• параллельные jobs делят время по числу раннеров — кэшируйте, а не плодите задачи.

budget:
  timeout: 30m    # верхний предел времени

18. GitLab Pages

GitLab Pages публикует статический сайт прямо из пайплайна: настройка в Settings → Pages, готовый сайт живёт на https://user.gitlab.io/project/ или собственном домене. Пайплайн собирает сайт так:

pages:
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - public
  only:
    - main

Главное правило — артефакт с именем каталога public: GitLab берёт его содержимое как корень сайта. Подходит любой статик-генератор: Vite, Jekyll, MkDocs, генераторы документации.

Отлично работает пара «docs-в-репозитории»: Markdown-документация собирается MkDocs и публикуется на Pages после каждого merge.

19. Продвинутый Git: rebase, cherry-pick, reflog

Для уверенной работы с командной историей необходимы три инструмента:

• git rebase — переносит коммиты ветки поверх актуального main: история линейная, конфликты решаются до открытия MR;
• git cherry-pick <hash> — применяет выбранный коммит на другую ветку (срочный фикс из ветки разработки на main);
• git reflog — журнал всех перемещений HEAD, спасает после случайного git reset --hard.

git switch feature/login
git fetch origin
git rebase origin/main
# при конфликтах: исправить → git add → git rebase --continue

20. glab CLI, API и вебхуки

Команда glab — терминальный интерфейс GitLab, аналог gh для GitHub. Авторизация — glab auth login с персональным токеном:

glab mr create --fill --title "Фикс логина"
glab mr list --mine
glab pipeline list
glab release create v1.0.0

CLI работает поверх REST API GitLab, которым можно скриптовать всё видимое в интерфейсе: от массового переименования переменных группы до создания issues из файла.

Webhooks GitLab отправляют POST на твой сервер при push, создании MR, завершении пайплайна. Сценарии: уведомления в мессенджер, синхронизация с внешними трекерами, автодеплой по триггеру.

21. Частые ошибки новичков

• дюжина коммитов «правки» вместо одного чистого — склеивай через rebase -i + squash;
• пуш напрямую в main при выключенной защите веток — правило Protected branches из раздела 13;
• закоммиченный .env — секреты попали в историю навсегда, ключи теперь скомпрометированы;
• гигантские MR на тысячи строк — разбивай на логичные, ревью тогда реально происходит;
• старт ветки без git pull — конфликты из-за устаревшего main всплывают в самый неподходящий момент;
• пайплайн без timeout — зависший job съедает раннеры и квоту минут;
• новые репозитории по умолчанию с веткой master — задай main и защиту default-ветки сразу при создании.

Чек-лист перед MR: тесты прошли, SAST и Secret Detection без критичных, ветка обновлена с main, ревьюер назначен, мерж-стратегия выбрана (squash).

Что дальше

Теперь ты владеешь основами Git и GitLab: от первого коммита до автоматизации развёртывания. Рекомендуемый следующий шаг — изучение Docker для упаковки приложений и запуска раннеров, а также Python, если уже готов писать тесты и скрипты для конвейеров.

← Вернуться к курсам