Как проводить проверки кода с помощью запросов на слияние GitLab

Мерж-реквесты GitLab — это ваш шанс проверить код до того, как он войдет в основную ветку вашего проекта. Запрос на слияние (MR) — это оболочка для операции git merge, доступная в веб-интерфейсе GitLab. После того, как вы просмотрели свой код, вы можете инициировать слияние одним щелчком мыши. Принятие рабочего процесса на основе MR помогает вам гарантировать качество кода, создавая ожидание того, что все коммиты тщательно проверяются.

Мерж-реквесты — один из основополагающих элементов GitLab. Они объединяют управление проектами, репозиторий и системы CI/CD на одной странице для каждого изменения в вашей кодовой базе. В этой статье мы используем GitLab CE с открытым исходным кодом. Коммерческие уровни имеют доступ к дополнительным функциям.

Создание запроса на слияние

Вы можете создать новый MR из GitLab, перейдя в Repository > Branches на боковой панели. Убедитесь, что вы отправили изменения из вашей локальной ветки в GitLab. Найдите ветку, которую вы хотите объединить, и нажмите кнопку «Запрос на слияние» справа от ее названия.

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

В нижней части страницы вы найдете элементы управления для установки уполномоченного, рецензента, контрольной точки и меток MR. Их можно изменить в любое время, используя правую боковую панель на странице сведений о мерж-реквесте. Мы рассмотрим их более подробно позже.

Вы можете пройти первоначальную проверку, не отправляя MR. Используйте вкладки «Commits» и «Changes», чтобы подтвердить, что вы включили правильный код. Когда будете готовы, нажмите зеленую кнопку «Отправить запрос на слияние», чтобы открыть MR. Вы можете просмотреть все MR в вашем проекте, используя ссылку «Merge Requests» на боковой панели.

Создание запросов на слияние из вашего терминала

Создание MR с помощью пользовательского интерфейса GitLab побуждает вас точно помечать MR метками, вехами и описательным текстом. Тем не менее, это трудоемкий процесс, который может занимать значительное время в течение дня. GitLab поддерживает параметры Git push, которые позволяют одновременно отправлять ветку и создавать MR.

git push -u origin HEAD -o merge_request.create -o merge_request.target=master

Использование git push с параметрами, показанными выше, переместит вашу текущую ветку на ваш удаленный Git. Удаленная ветка будет создана заново с тем же именем, что и ваша локальная ветка, если она еще не существует. Две опции -o будут обработаны GitLab. Они приведут к открытию нового MR для слияния вашей ветки с master.

GitLab автоматически заполнит заголовок и описание MR, используя информацию из вашего последнего коммита. Кроме того, вы можете указать проблему GitLab в своем сообщении о коммите — например, Fixes #123 — чтобы GitLab автоматически применяла свои метки и вехи к MR.

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

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

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

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

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

Внесение изменений в ваш код

Несмотря на все ваши усилия, иногда вы просматриваете свой MR и обнаруживаете проблему, которую раньше не замечали. Однако вам не нужно сразу возвращаться в редактор кода. На экране «Изменения» есть средства, которые помогут вам исправить ошибки по мере их обнаружения.

Для простых однострочных исправлений наведите указатель мыши на нужную строку. Щелкните значок комментария, который появляется слева от строки. Появится редактор комментариев со стандартным редактором GitLab Markdown. Вы можете использовать эту возможность, чтобы комментировать определенные строки в вашем MR — ваши сообщения снова появятся на вкладке «Обзор». Мы ищем конкретную функцию, кнопку «Вставить предложение» на панели инструментов.

Нажмите кнопку, чтобы вставить выбранную строку в ваш комментарий. Используйте редактор комментариев, чтобы отредактировать строку, чтобы она должна выглядеть. Затем нажмите «Начать обзор» или «Добавить комментарий сейчас». Первый позволяет вам хранить несколько комментариев вместе, чтобы отправить их в виде пакета после завершения проверки.

После того, как вы сохраните свой комментарий, вы увидите виджет «Предлагаемое изменение» под подозрительной строкой. Это отобразит новый diff для применения. Нажмите кнопку «Применить предложение», чтобы мгновенно внести изменения.

Использование предложений может значительно сократить время на устранение незначительных проблем, поскольку вам не нужно выходить из браузера. Для более длительного редактирования вы можете щелкнуть значок с тремя точками рядом с любым файлом на экране «Изменения», чтобы открыть его в полной веб-среде GitLab Web IDE.

Черновые (незавершенные) запросы на слияние

Иногда вам нужно отправить код до того, как он будет готов к слиянию. Вы можете отличить эти MR, добавив к их названию префикс «Черновик» или нажав кнопку на панели инструментов. Черновики MR нельзя объединить, пока вы вручную не отзовете их статус черновика, нажав «Отметить как готовые» в правом верхнем углу.

Эта функция раньше называлась «Work-in-Progress» с использованием префикса названия «WIP». От этой терминологии теперь отказались в пользу «черновика», который будет единственным поддерживаемым вариантом в GitLab 14. Обе формы доступны в GitLab 13.

Когда вы добавляете коммиты в свои MR, они будут перечислены в разделе «Обзор» на странице MR. Вы можете щелкнуть ссылку «Сравнить с предыдущей версией», чтобы увидеть различия этих изменений отдельно.

При нажатии на вкладку «Изменения» без выбора версии отображается разница всего MR относительно целевой ветки. Вы можете просмотреть различия между любыми двумя версиями, используя раскрывающиеся списки «Сравнить [основную] и [последнюю версию]» в верхней части экрана «Изменения».

Завершение обзора

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

Чтобы сообщить, что MR готов к объединению, используйте синюю кнопку «Подтвердить». Это не влечет за собой никаких действий внутри GitLab, за исключением сообщения вашей команде о том, что MR принят. Затем вы можете продолжить и объединить MR, нажав зеленую кнопку «Объединить».

Используйте флажок «Удалить исходную ветку», чтобы указать, будет ли ветка удалена после слияния. Это помогает сократить список веток, но может привести к потере контекста в будущем. Опция «Squash commits» позволяет объединить все коммиты в MR в один. Это создает более аккуратную историю коммитов, но затрудняет откат отдельных изменений в будущем. Доступность этих параметров будет зависеть от настроек, определенных в вашем проекте и вашей группе.

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

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