Как работать с Gitlab

В данном разделе мы познакомим Вас с нашими правилами работы в системе контроля версий GitLab.

Git требует какой-то пароль?

Вам необходимо создать ssh ключ для git. Тут описано как это сделать.

Все равно требует пароль? Убедись, что ты клонируешь с помощью ssh, а не https

Как брать задачи

Команда будет назначать Вам задачи и весь список будет находиться у Вас в разделе issues.

Также есть kanban доски. Которые находятся в левой боковой панели по пути Plan/Issue boards. Общая доска задач

У issue есть свой приоритеты:

Оценка - Лейбл устанавливается на задачи, которые требуют оценки времени реализации задачи (Если у вас появилась такая задача, необходимо в комментарий написать время, которое вам потребуется для решения задачи)
Ожидает подтверждения руководителя - Лейбл устанавливается на задачи, которые вы оценили по ресурсозатрантости
На перспективу - приоритет = 1, запланированные задачи на следующие версии проекта
Не критично - приоритет = 2, согласованы, но не несут в себе важных решений
Приоритетно - приоритет = 3, задача в рамках рабочего плана
Срочно - приоритет = 4, задачу нужно взять сразу как только ты увидел ее в списке

Помимо приоритетов существуют Статусы задач, они так же определяются лейблами

В работе Ставишь, как только ты взял задачу в работу
Ревью Ставишь, когда по твоему мнению задача готова к проверке
На проверке QA В нашей команде есть QA инженер, после поверхностой проверки твоего кода на грубые ошибки, задача отправляется на детальное тестирование
На проверке у заказчика Ставит руководитель, после того как QA ринял задачу и она соответсвует нашим нормам
Принята Задачу принял заказчик и команда

Так же есть дополнительные лейблы для команды

Вопросы по формулировке Ставится, когда ты не понимаешь описания задачи и тебе нужно расписать ее подробнее (В комментариях обязательно пиши свой вопрос)
Не активна Ставится, если по какой-то причине заказчик/руководитель решил, что эта задача не нужна
Требует доработки админки Ставится, если ты не можешь решить поставленную задачу без доработки админ. части системы
Требует доработки ядра (для менее опытных сотрудников) Если ты понимаешь, что публичной части не достаточно для решения проблемы и требуется доработка ядра API, ставь этот лейбл
Требует доработки API (для Frontend разработчиков) Ставится, если ты не можешь решить поставленную задачу без доработки серверной части системы
Требует вмешательства Ставишь, когда понимаешь, что задачу самостоятельно решить ты не в силах, по причине недостатка навыков пппонимания системы
Сформирована QA Лейбл устанавливает QA инженер, в случае если задача не является результатом проверки конкретной задачи.

Я взял задачу, что дальше?

Сперва необходимо добавить задаче метку В работе, показав таким образом команде, что она в работе, а затем создать свой feature branch - ветку в которой Вы будете работать. Проще всего сделать это в репозитории:

Но никто не запрещает Вам сделать ветку в git локально и пушить ее уже перед созданием merge request

Полный путь задачи

Задача требует оценки:

Открытие задачи
Установке лейбла "Оценка"
Исполнитель переходит в задачу и в комментариях пишет, сколько часов ему нужно на реализацию
Установке лейбла "Ожидает подтверждения Руководителя"
Руководитель подтверждает задачу, устанавливая приоритет
Вы берете задачу
Установке лейбла "В работе"
Вы выполняете задачу
Создаете МР
Установке лейбла "Ревью"
Руководитель проверяет ваш код
Установке лейбла "На проверке QA"
QA проверяет задачу. Если есть баги, пишет их в комментарии и отправляет задачу обратно в лейбл "В работе", в этом случае задача после правок проходит тот же путь до проверки QA
Установке лейбла "На проверке у заказчика"
Проверка заказчиком. Если есть баги, они будут в комментариях, задача отправляется обратно в лейбл "В работе"
Установке лейбла "Принята"
Выгрузка в релиз
Закрытие задачи

Задача не требует оценки:

Открытие задачи
Вы берете задачу
Установке лейбла "В работе"
Вы выполняете задачу
Создаете МР
Установке лейбла "Ревью"
Руководитель проверяет ваш код
Установке лейбла "На проверке QA"
QA проверяет задачу. Если есть баги, пишет их в комментарии и отправляет задачу обратно в лейбл "В работе", в этом случае задача после правок проходит тот же путь до проверки QA
Установке лейбла "На проверке у заказчика"
Проверка заказчиком. Если есть баги, они будут в комментариях, задача отправляется обратно в лейбл "В работе"
Установке лейбла "Принята"
Выгрузка в релиз
Закрытие задачи

Слияние с основной веткой

Для того чтобы Ваш код ушел в основную ветку необходимо создать запрос на слияние merge request. Делается это в левой боковой панели. Раздел Merge requests. Вам нужно создать новый запрос, выбрав из какой ветку в какую будет выполниться слияние. Или перейти по ссылки в терминали после пуша.

Вам необходимо заполнить заголовок и описание merge reqeust

Заголовок заполняется в формате [Краткое описание проделанных работ] #[номер issue]. В описании есть несколько разделов, которые необходимо заполнить. Если Вам кажется что какой-то из них лишний, то не удаляйте его, а просто оставьте незаполненным. В описании есть блоки такого формата: . Это комментарии, которых не видно, пока Вы редактируете файл. Удалять их не стоит. Они нужны Вам просто как подсказки

How to issue

Как же создать задачу и когда это можно сделать? Да в целом всегда. У Вас предложение - новое issue. Вам пишет заказчик с просьбой чет починить? Добавь issue. Наткнулись на что-то склизкое, мягкое и неприятное на запах в процессе разработки - ... правильно - заводим issue

При оформлении issue необходимо дать ей адекватный заголовок. Вкратце изложить проблему, а затем в описании дать максимально много информации, которой Вы владеете. Важно, чтобы в описании прослеживалась ЦЕЛЬ - что вообще необходимо сделать. Чем лучше описана issue тем лучше, но стоит учитывать issue, в основном, НЕ ЯВЛЯЕТСЯ ИНСТРУКЦИЕЙ К ДЕЙСТВИЮ. Если в issue описаны требования, то Вы обязаны их выполнить или обсудить, но то как это сделать решать Вам.

Я хочу сослаться на issue, merge request, разработчика

Чтобы вставить ссылку на issue или merge request, достаточно просто скопировать url и вставить в описание/комментарий/заголовок. Есть еще один способ это сделать. Чтобы обратиться к issue того же проекта, в котором вы работаете, достаточно написать #[номер issue] или для merge request ![номер merge request]. Если Вы хотите сослаться на другой проект, то необходимо указать его название перед # или ! (core#123, core!321).

Если нужно тегнуть кого-то, то используйте @. Например: @codedlife

Мой merge/issue зависит от другого в другом проекте

Если так вышло, что Ваша работа зависит от правок другого человека или одно задача завит от другой, то необходимо это указать написав в описании issue Blocked by #[номер issue]

Вот черт! Кто-то уже обновил тот же файл, что и я

Если при слиянии у Вас появились конфликты, то это явный сигнал о том, что необходимо сделать rebase с основной веткой. Делается это следующим образом:

Необходимо обновить локальную main ветку

git chechout main
git pull
git chechout [Ваша ветка]

Выполнить rebase

git rebase [Ветка откуда будет rebase - (main)]

В процессе могут возникнуть конфликты, которые необходимо будет решать. Читайте вывод в консоль и открывайте файлы, о которых Вам пишет git. Обычно IDE сама предлагает Вам выполнить слияние, когда Вы открываете конфликтный файл.
Когда Вы закончили с файлом Вам необходимо вернуться в консоль, добавить правки и продолжить слияние

git add .
git rebase --continue

Выполняйте последние пару пунктов до тех пор, пока git не перестанет жаловаться
Затем необходимо запушить правки в Вашу ветку выполнив

git add .
git commit -m "Слияние ветки с main"
git push --foorce-with-lease

By codedlife & naweedu

25 ноября 2025