GitLab labels: зачем нужны и как использовать в команде

GitLab labels — это метки для задач и merge request. Они помогают быстро понять состояние работы, тип изменений, зону ответственности и возможные ограничения без чтения всей переписки. Единые правила снижают риск случайного merge, упрощают планирование и делают доски задач более понятными.

Принципы использования labels

Labels должны быть короткими, однозначными и применяться по понятным правилам. Лучше использовать единый стиль: например, технические названия в snake_case или через префиксы. Не стоит создавать несколько меток с одинаковым смыслом: bug, issue и defect быстро создадут путаницу.

Один label — один смысл.

Автор задачи или merge request добавляет метки при создании.

Тот, кто меняет статус работы, обновляет и labels.

Временные метки снимаются сразу после того, как причина исчезла.

Цвета стоит закрепить по категориям: красный — блокировки и ошибки, жёлтый — внимание, зелёный — готовность, синий — область или тип работы.

Основные labels команды

`draft`

Используется для незавершённой задачи или merge request, который ещё рано полноценно ревьюить и вливать. Метка показывает, что автор продолжает работу, может менять архитектуру или ждёт уточнений.

Ставить: работа не завершена, есть незакрытые вопросы, MR создан для ранней обратной связи.

Снимать: изменения готовы к ревью, описание заполнено, проверки запущены.

Рекомендация: для merge request дополнительно использовать статус Draft в самом GitLab, если он доступен.

`need_help`

Нужен, когда автор не может продолжить работу без помощи команды: требуется решение по архитектуре, консультация по модулю, доступ, уточнение требований или парное программирование.

Ставить: есть конкретный блокирующий вопрос, который не удалось решить самостоятельно.

В описании обязательно указать: что уже проверено, в чём проблема и какая помощь нужна.

Снимать: решение найдено или вопрос передан ответственному человеку.

`dont_merge`

Критическая защитная метка: merge request нельзя вливать, даже если пайплайн успешен и есть одобрения. Она полезна для временных ограничений, неготовых миграций, зависимостей от релиза или ручной проверки.

Ставить: merge может повредить окружению, нарушить совместимость или должен ждать внешнего события.

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

Снимать: только после проверки причины автором или ответственным за ограничение.

Рекомендация: использовать красный цвет и не применять метку для обычного ревью.

`refactoring`

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

Ставить: основная цель задачи — улучшить внутреннее устройство кода.

В описании указать, какие части затрагиваются и как подтверждается отсутствие регрессий.

Можно сочетать с testing, если требуется расширить покрытие тестами.

`fsd`

Используется для задач и merge request, затрагивающих Feature-Sliced Design: слои, слайсы, публичные API модулей, импортные правила и архитектурные границы.

Ставить: изменение связано с миграцией на FSD, созданием или перестройкой слайсов, исправлением нарушений архитектуры.

В описании указывать затронутые слои и причину изменения.

Полезно назначать ревьюера, знакомого с архитектурными соглашениями проекта.

Дополнительные полезные labels

bug — ошибка в существующем поведении, требующая исправления.

feature — новая пользовательская возможность или заметное расширение функциональности.

documentation — изменения документации, инструкций, README или описаний API.

priority::high — важная задача, которую нужно взять в работу раньше обычных.

priority::medium — стандартный приоритет.

priority::low — задача без срочности, подходящая для плановой работы.

frontend — изменения интерфейса, клиентской логики или фронтенд-инфраструктуры.

backend — изменения серверной логики, API, базы данных или интеграций.

testing — добавление, исправление или переработка тестов.

blocked — работа остановлена внешней зависимостью: ожиданием решения, доступа, другой задачи или релиза.

Для иерархических групп удобно использовать префиксы: type::bug, area::frontend, priority::high, status::blocked. Такой формат хорошо масштабируется, фильтруется в GitLab и делает смысл метки заметным сразу.

Примеры использования

Исправление ошибки в интерфейсе

Задача с проблемой отображения формы может получить labels: bug, frontend, priority::high. Если разработчик ждёт ответа от API-команды, добавляется blocked или need_help — в зависимости от того, нужна ли консультация или работа действительно остановлена.

Незавершённый merge request с архитектурными изменениями

MR по переносу модуля на FSD может иметь labels: draft, fsd, refactoring, frontend. Когда код готов к ревью, автор снимает draft. Если вливать изменения можно только после релиза другой части системы, добавляется dont_merge с пояснением в описании.

Новая функциональность с тестами

Для задачи на добавление новой возможности подойдёт набор: feature, frontend или backend, testing, priority::medium. Если требуется подготовить инструкцию для команды, добавляется documentation.

Чек-лист для авторов и ревьюеров

При создании задачи указан тип работы: bug, feature, refactoring или другой понятный label.

Добавлены labels области: frontend, backend, fsd, если они применимы.

Указан приоритет, если задача попадает в планирование.

Для незавершённой работы установлен draft.

При любой блокировке добавлен blocked, need_help или dont_merge с пояснением.

Перед merge сняты временные метки: draft, need_help, blocked, dont_merge.

Для архитектурных и рискованных изменений назначены подходящие ревьюеры.

Вывод

Начните с небольшого и устойчивого набора: draft, need_help, dont_merge, refactoring, fsd, а также bug, feature, documentation, frontend, backend, testing, blocked и приоритетов. Регулярно пересматривайте labels: если меткой никто не пользуется или её смысл пересекается с другой, лучше объединить или удалить её. Цель labels — не усложнить процесс, а сделать состояние работы очевидным для всей команды.