что такое мерж реквест

Изучаем Git. Урок 24.
Мердж-реквесты и код-ревью

Видеоурок

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Что такое мердж-реквест?

Зачем нужны мердж-реквесты?

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

Как правильно: merge request или pull request?

Как проходит процедура мердж-реквеста

Немного о markdown

Markdown позволяет форматировать текст: задавать заголовки, списки, цитаты, вставлять ссылки и картинки и даже форматировать код. Насчет кода, возможно, для приграммиста это самая удобная фишка markdown, так как используется достаточно часто

Изучается markdown быстро, разметка очень простая. Вот пример оформления списка, используются звездочки

А вот пример оформления кода, используются апострофы

После этого ваш текст красиво отформатируется, можете попробовать в любом markdown онлайн-редакторе, например, dillinger.io/

Совет от автора

Немного о код ревью

Это отдельная большая тема и git она не касается. Поэтому приведу только кратко причины проводить код ревью

Вопросы на код ревью могут быть совершенно разные и на разные темы. Это всего лишь краткий перечень плюсов от код ревью

Как оповестить коллег о новом мердж-реквесте

Здесь разные варианты, зависит от договоренностей в команде.

Главное договориться как будет удобнее всем в вашей команде

Кто принимает мердж-реквесты

Здесь тоже могут быть разные варианты:

Немного о работе в команде

Источник

В чем отличие Pull Request от MergeRequest?

Пользовался различными репозиториями(GitHub,Bitbucket,GitLab). В каждом репозитории одно и тоже действие называется по разному. В чем отличие Pull Request от MergeRequest? Почему называются Pull Request и MergeRequest? Может это из-за того что под капотом разные команды?

2 ответа 2

Merge Request и Pull Request это один и тот же функционал, который в разных репозитариях просто называется по разному, об этом можно почитать здесь. И то и другое обозначает один и тот же процесс, в GitHub и Bitbucket называют операцию pull request, потому что первое действие, которое совершит человек, который будет вливать себе правки из request это git pull, тогда как GitLab и Gitorious называют это действие merge request, потому что финальным действием будет слияние изменений (git merge)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками git github pull-request или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.11.19.40795

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

GitLab

Work in branches

Этот документ объясняет механизм ветвления и то, каким образом публиковать свои изменения в GitLab.

Терминология

master: главная ветвь проекта. Обычно ветки создаются от master. Вы не должны делать свою работу напрямую в master и должны создавать новые ветки для каждой задачи над которой вы работаете самостоятельно или сообща. Когда работа закончена выполняется слияние вашей ветки обратно в master. Ветвление и слияние в Git должно стать частью вашего ежедневного рабочего процесса.

origin: основной удалённый репозиторий в котором вы публикуете свои изменения и из которого получаете изменения других разработчиков.

Ветки

Две основные долгоживущие ветки:

Настройка GitLab аккаунта

GitLab должен знать что вам разрешено делать, а что нет. Для этого вам нужно настроить доступ по SSH-ключам. Это описано здесь

Цикл разработки

Мы используем подход, основанный на мерж-реквестах. Багфиксы и доработки должны быть опубликованы в собственной ветке разработчика, которая создаётся специально под задачу.
Затем создаётся запрос на слияние новой ветки с веткой master в основном репозитории. Следует избегать публикации непосредственно в ветку master.

Правила именования коммитов

Комментарии к правкам следует писать по-русски в кодировке UTF-8.
Многострочный комментарий состоит из однострочного заголовка отделённого от тела пустой строкой.
Длина строки заголовка и тела не должна превышать 80 символов.
Тело комментария должно содержать информацию о том что сделано и зачем это было сделано.
Многострочный комментарий используется при необходимости детализировать назначение набора изменений.
Если правка относится к задаче в трекере, в заголовке указывается номер задачи Jira.

IS-1276. Экспорт РПП в формат CSV. Выгрузка НДС в назначении платежа.

Правила именования веток

Имена функциональных веток должны кратко, в 1-2-3-4 слова (слова разделяются дефисом), характеризовать назначение ветки.
Нет необходимости включать в наименование ничего не значащие или понятные только вам аббревиатуры, постфиксы, указания на нежелаемое поведение.

Хороший пример: fix-service-control

Создание merge request

Идём на GitLab, находим модуль, в котором мы опубликовали свою ветку, далее на закладке Merge requests и нажимаем кнопку Create merge request.

Вводим Title. Заголовок обязательно должен включать номер задачи в Jira и тему, характеризующую изменения.
В Description можем указывать какие именно изменения были сделаны, почему предпочтение отдано именно такому подходу.
Дополнительно здесь можно указать информацию, которая может быть полезна ревьюверу чтобы сориенироваться в предлагаемых правках.
А также упомянуть тех, кому эти изменения могут быть интересны (чьё мнение вам важно). Для этого введите /cc @
Здесь работает markdown-синтаксис.
Проверяем что в список Changes попали только коммиты с вашей ветки.
Выбираем того, кому предстоит принимать ваш запрос из выпадающего списка Assignee.
Ставим галку Remove source branch when merge request is accepted.
Жмём Submit merge request. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.

Больше мерж-реквестов

Для набора изменений, затронувшего несколько модулей, если изменения в этом модуле не совсем тривиальны и нуждаются в ревью (см. ниже раздел «Когда направлять мерж-реквест, а когда нет»), создаётся по одному мерж-реквесту на каждый модуль.
Имена веток во всех модулях должны совпадать. Для навигации между ними в описании добавляются перекрёстные ссылки.

Кто принимает мерж-реквест

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

Ревьюверу следует обращать внимание на:

Комментарии и замечания должны находиться непосредственно в данном мерж-реквесте.

Исправления замечаний делаются в той же ветке и видны в мерж-реквесте.

Источник

Gitlab merge request: как сделать и принять MR

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

ip адрес в примере используется только для демонстрации, его нужно заменить на свой.

git clone git@ip-address:root/myproject.git

Теперь на локальном компьютере присутствуют скрипты проекта, или один скрипт index.py как в примере.

Переходим в каталог

Теперь можно создать новую ветку

В ней вносим изменения

Открыв файл в текстовом редакторе добавим комментарий

Затем добавляем все содержимое каталога на staging

И заливаем в ветку update-code

После обновления страницы в интерфейсе Gitlab будет отображаться вторая ветка

Рядом с именем ветки есть кнопка Merge request

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

Также можно установить, что нужно чье-либо одобрение для принятия Merge-request и слияния с веткой master.

После заполнения полей формы нужно нажать «Submit merge request» внизу.

Теперь тот кому отправлен MR получит оповещение и сможет увидеть все внесенные изменения, затем закрыть MR, выполнить слияние с master или начать дискуссию.

Нажатие на первую позволит увидеть разницу до и после внесения изменений, код будет выводиться на экране разделенном на две части вертикально. Аналогично git diff.

Если выбрать «Check out branch» — отобразится инструкция с командами, позволяющими скачать изменений на локальный компьютер, исправить все конфликты и загрузить в репозиторий.

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

В консоли когда merge выполнен, можно переключиться на master и забрать через pull изменения.

Изменения будут залиты в master. Найдя MR всегда можно воспользоваться опцией revert для отмены.

Источник

Анализ merge request’ов в GitLab с помощью PVS-Studio для C#

Любите GitLab и не любите ошибки? Хотите повысить качество исходного кода? Тогда вы попали по адресу. Сегодня мы расскажем, как настроить C# анализатор PVS-Studio для проверки merge request’ов. Всем единорожного настроения и приятного чтения.

PVS-Studio — это инструмент для выявления ошибок и потенциальных уязвимостей в исходном коде программ, написанных на языках C, C++, C# и Java. Работает в 64-битных системах на Windows, Linux и macOS. Может анализировать код, предназначенный для 32-битных, 64-битных и встраиваемых ARM платформ.

Кстати, у нас состоялся релиз PVS-Studio 7.08, в котором мы сделали много всего интересненького. Например:

Режим проверки списка файлов

Если вам интересно настроить проверку коммитов или pull requests, вы также можете сделать это, используя данный режим. Отличие будет заключаться в получении списка файлов для анализа и зависеть от того, какие системы вы используете.

Принцип проверки merge request

Основная суть проверки состоит в том, чтобы проблемы, обнаруженные анализатором, при слиянии не попадали в master ветку. Также мы не хотим каждый раз анализировать проект целиком. Тем более что при слиянии веток у нас есть список измененных файлов. Поэтому предлагаю добавить проверку merge request.

Вот так выглядит merge request до внедрения статического анализатора:

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

Анализируем changes2 и, если ошибок нет, принимаем merge request, а иначе отклоняем его.

Кстати, если вас интересует анализ коммитов и pull request’ов для C/C++, то вы можете почитать об этом здесь.

GitLab

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайном и другими функциями.

Перед тем как приступить к реализации анализа merge request’ов необходимо зарегистрироваться и загрузить свой проект. Если вы не знаете, как это сделать, то предлагаю статью моего коллеги.

Примечание. Описываемый далее способ настройки окружения – один из возможных. Цель – показать шаги настройки необходимого для анализа окружения и запуска анализатора. Возможно, в вашем случае более оптимальным будет разделение этапов подготовки окружения (добавление репозиториев, установка анализатора) и анализа: например, подготовка Docker образов с необходимым окружением и их использование или какой-нибудь иной способ.

Чтобы нагляднее понять, что сейчас будет происходить, я предлагаю взглянуть на следующую схему:

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

Для работы анализатору необходим лицензионный ключ. Получить пробную лицензию можно на странице загрузки анализатора.

Примечание. Обратите внимание, что для описываемого режима работы (анализ merge requests) нужна Enterprise лицензия. Поэтому, если вы хотите попробовать данный режим работы, в поле «Сообщение» не забудьте указать, что вам нужна именно Enterprise лицензия.

Если происходит merge request, то нам потребуется проанализировать только список измененных файлов, а иначе анализируем все файлы. После анализа нужно сконвертировать логи в нужный нам формат.

Вот теперь мы готовы к написанию скрипта. Давайте сначала напишем код, который установит анализатор и введет лицензию:

Так как установка и активация должна происходить перед всеми другими скриптами, то используем специальную метку before_script. Немного поясню данный фрагмент.

Подготовка к установке анализатора:

Добавление репозиториев PVS-Studio и анализатора:

$PVS_NAME — имя пользователя.

$PVS_KEY — ключ продукта.

Восстановление зависимостей проекта, где $CI_PROJECT_DIR – полный путь до директории проекта:

Для корректного анализа проект должен успешно собираться, а его зависимости должны быть восстановлены (например, должны быть загружены необходимые NuGet пакеты).

Задать переменные окружения, содержащие лицензионную информацию, можно, нажав на Setting, а после — на CI / CD.

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

Теперь можно переходить к анализу. Сначала добавим скрипт для полного анализа. В флаг -t передаем путь до solution, в флаг -o пишем путь до файла, в который будут записаны результаты анализа. Также нас интересует код возврата. В данном случае нам интересно, чтобы работа прекращалась, когда код возврата содержит информацию о том, что в ходе анализа были выданы предупреждения. Вот как выглядит данный фрагмент:

В данном случае нас интересуют все коды возврата, где фигурирует 8.

Мы получим 1, когда код возврата содержит интересующий нас бит числа, а иначе получим 0.

Настало время добавить анализ merge request. Перед тем как это сделать, подготовим место для скрипта. Нам необходимо, чтобы он выполнялся только тогда, когда происходит merge request. Выглядит это вот так:

Перейдем к самому скрипту. Я столкнулся с тем, что виртуальная машина ничего не знает про origin/master. Поэтому помогаем ей немного:

Теперь получим разницу веток и сохраняем результат в txt файл:

Где $CI_COMMIT_SHA – хеш последнего коммита.

Полный скрипт для проверки merge request будет выглядеть вот так:

Остается только добавить конвертацию лога после того, как отработали все скрипты. Используем метку after_script и утилиту plog-converter:

Утилита plog-converter — это open source проект, который используется для преобразования отчета об ошибках анализатора в различные формы, например, HTML. Более подробное описание утилиты приводится в подразделе «Утилита Plog Converter» соответствующего раздела документации.

Для удобства вот .gitlab-ci.yml целиком:

Увидели Job succeeded – успех, все прекрасно. Теперь можно и протестировать сделанное.

Примеры работы

Для примера работы создадим простой проект (в master) в котором будет несколько файлов. После этого в другой ветке изменим только один файл и попробуем сделать merge request.

Рассмотрим два случая: когда измененный файл содержит ошибку и когда нет. Сначала пример с ошибкой.

Допустим, в master ветке есть файл Program.cs, который не содержит ошибок, а в другой ветке разработчик добавил ошибочный код и хочет сделать merge request. Какую именно ошибку он допустил – не столь важно, главное, что она есть. Например, забыл оператор throw (да, так ошибаются):

Посмотрим на результат анализа примера с ошибкой. Также чтобы убедиться в том, что только один файл был проанализирован, я добавил флаг -r в строку запуска pvs-studio-dotnet:

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

Проверяем пример без ошибки. Исправляем код:

Результаты анализа merge request:

Как мы видим, ошибки не найдены, и исполнение задачи прошло успешно, что мы и хотели проверить.

Заключение

Отсеивать плохой код до слияния веток — это очень удобно и приятно. Поэтому, если вы пользуетесь CI/CD, попробуйте встроить статический анализатор для проверки. Тем более что делается это достаточно просто.

Источник