Когда разработчик приходит в новую компанию, первое, с чем ему приходится разбираться, — это GitLab. Без него ничего не получится: весь код хранится там, туда отправляются изменения, оттуда собираются релизы. Сначала кажется, что GitLab — просто сайт с проектами, но быстро становится понятно, что это сердце всей разработки.

И первый шаг — не клонировать репозиторий, а получить доступ. Обычно корпоративный GitLab не принимает обычные пароли. Вместо этого используются personal access tokens — персональные токены доступа. Это, по сути, твой цифровой пропуск, который GitLab использует для проверки прав.

Подключение к GitLab по токену

Чтобы начать работать, нужно зайти в свой профиль в GitLab. В разделе Preferences → Access Tokens есть форма, где можно создать токен. Обычно просят заполнить имя, например local-dev, выбрать срок действия (в компаниях это бывает 30 или 90 дней) и отметить права — достаточно read_repository и write_repository, чтобы можно было читать и записывать код.

После нажатия кнопки Create personal access token GitLab покажет длинную строку — она выглядит примерно так:

glpat-ABCD1234efgh5678ijkl

Эту строку нужно сразу сохранить. GitLab покажет её только один раз, и если потерять, придётся создавать новую.

Дальше всё просто. Когда появляется доступ, можно клонировать проект. Репозиторий обычно находится по адресу вроде:

git clone https://gitlab.company.com/team/project.git

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

Как устроен Git и зачем он нужен

Многие воспринимают Git как «место, где лежит код», но это не совсем так. Git — это система контроля версий. Он хранит всю историю изменений проекта, позволяет откатить любую правку, вернуться к старой версии или понять, кто, когда и зачем поменял строку кода.

Git устроен вокруг понятия веток. Есть основная ветка — обычно main, и от неё отходят другие ветки — под фичи, багфиксы и эксперименты. Каждый разработчик работает в своей ветке, чтобы не мешать другим. Это и есть то, что делает Git мощным: несколько человек могут одновременно менять проект, а потом объединить свои изменения.

Основная ветка и правила работы

В команде почти всегда есть одно железное правило — в main руками не пушим.
main — это стабильная ветка, в которой всегда лежит проверенный и готовый к деплою код. Она должна быть в рабочем состоянии в любой момент. Любая ошибка в main мгновенно может попасть на прод, поэтому защита тут обязательна.

Всё, что разрабатывается, делается в отдельных ветках.

Названия веток обычно строятся по шаблону:

• feature/... — новая функциональность
• fix/... — исправление ошибки
• chore/... — технические изменения, которые не влияют на поведение

Например:

feature/add-user-search
fix/login-error
chore/update-dependencies

Это не просто формальность. Когда потом кто-то смотрит историю, по названию сразу понятно, зачем эта ветка существовала.

Начало работы над задачей

Перед началом любой задачи нужно убедиться, что локальный main совпадает с серверным.
Для этого выполняется:

git checkout main
git pull

Если есть последние изменения, они подтянутся. После этого создаётся ветка от main под новую задачу:

git checkout -b feature/add-user-search

Теперь у тебя собственная ветка, в которой можно спокойно менять код, не ломая общий проект.

Коммиты: зачем и как их делать

Всё, что происходит в ветке, Git фиксирует в коммитах.

Типичный рабочий цикл выглядит так:

git status          # посмотреть, что изменилось
git add src/search.ts
git commit -m "feat: добавлен поиск пользователей"

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

Главное — сообщения коммитов должны быть короткими и осмысленными. Писать «исправил баг» бесполезно — через месяц никто не вспомнит, какой именно баг. Лучше написать чётко:

fix: исправлена фильтрация пользователей по email

или

refactor: вынес логику поиска в отдельный модуль

Со временем вырабатывается привычка — писать коммиты так, чтобы любой коллега, открыв историю, понял, что произошло без просмотра диффа.

Отправка ветки в GitLab

Когда задача готова, ветку отправляют на сервер:

git push -u origin feature/add-user-search

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

После пуша GitLab сам предложит создать Merge Request. Это заявка на слияние твоей ветки с main.

Merge Request: сердце командной работы

Merge Request — это не формальность. Через MR код попадает в main, и именно тут проходит ревью. MR показывает, какие файлы изменены, кто автор, какие коммиты входят в ветку.

В описании MR обычно пишут три вещи:
что сделано, зачем и как проверить.
Пример:

Что сделано: добавлен поиск пользователей по имени и email
Как проверить: открыть страницу /users, ввести часть имени, убедиться, что поиск работает
Зачем: улучшение навигации в панели администратора

После создания MR назначаются ревьюеры — обычно один или два коллеги. Они просматривают код, оставляют комментарии, предлагают улучшения. Если нужно, автор правит у себя локально и пушит снова. MR автоматически обновляется — не нужно ничего создавать заново.

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

Обновление ветки и конфликты

Пока MR на ревью, main живёт своей жизнью — туда могут попадать другие изменения. Чтобы при слиянии не было конфликтов, ветку нужно обновлять.

Для этого выполняют:

git fetch origin
git rebase origin/main

Rebase переносит твои коммиты поверх актуального main, как будто ты их сделал позже. Если где-то код пересёкся, Git покажет конфликтные файлы. Их нужно открыть, вручную выбрать нужные изменения, сохранить и продолжить процесс:

git add .
git rebase --continue

Конфликты — это не катастрофа, это нормальная часть работы. Главное — не паниковать и внимательно смотреть, что сохраняешь.

Слияние в main

Когда ревью пройдено, все тесты зелёные, и никто не возражает, MR мёржится. В корпоративных репозиториях обычно включён режим Squash & Merge. Он объединяет все коммиты из ветки в один аккуратный коммит. Благодаря этому в main не накапливаются сотни мелких фиксов — каждая задача становится одним логическим блоком.

После слияния ветку удаляют, чтобы не плодить мусор:

git branch -d feature/add-user-search
git push origin --delete feature/add-user-search

Релизы и теги

Когда в main накопилось несколько задач, из них делают релиз. Чтобы зафиксировать момент, ставят тег:

git checkout main
git pull
git tag -a v1.2.0 -m "Добавлен поиск пользователей"
git push origin v1.2.0

Теги нужны для ориентира: по ним всегда можно узнать, что именно вошло в ту или иную версию.
CI/CD-система обычно автоматически собирает релиз по тегу и выкатывает его на сервер.

Если после релиза обнаружился баг, создаётся ветка от main, исправляется ошибка, создаётся новый MR и после мёрджа ставится новый тег — например, v1.2.1.

Зачем всё это и почему это удобно

• Git и GitLab — это не просто инструмент, а система порядка.
• Каждое изменение проходит путь от отдельной ветки до ревью и слияния.
• main остаётся стабильным, история проекта прозрачна, любой шаг можно восстановить.
• Разработчик не ломает чужой код, потому что работает в своей ветке.
• Ошибки не попадают в прод, потому что каждое изменение смотрят другие.
• И если вдруг что-то пошло не так — можно откатить конкретный коммит или вернуться к прошлому тегу.

И в этом весь смысл рабочего git-workflow — чтобы каждый шаг был под контролем и чтобы проект развивался без хаоса.