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

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

Видеоурок

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

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

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

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

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

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

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

Немного о markdown

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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 для отмены.

Источник

Гит-словарик для начинающих программистов

Мёржим бранчи и коммитим реквесты

Мы часто упоминаем Git — способ организации хранения и контроля версий файлов в рабочем проекте. Сегодня расскажем о странных словах: «бранч», «коммит», «пулл-реквест» и об остальных понятиях в гите.

О чём речь

Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.

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

На базе гита есть сервис «Гитхаб». Работает так:

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

Это если вкратце. Теперь будут подробности.

Что такое репозиторий (git repository)

Гит-репозиторий — это облачное хранение вашего проекта на сервере (например, на сервере Гитхаба, но можно и на другом).

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

В репозитории могут храниться:

Что такое бранч (git branch)

Бранч — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.

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

Дело в том, что ветка master используется для выпуска новых версий проекта, которые будут доступны всем. То, что добавляется в мастер-бранч, сразу становится доступно пользователям.

Но представьте такую ситуацию: мы только что запустили сайт для заказчика и он срочно хочет добавить интерактивный раздел со скидками. Можно сделать так: править рабочие файлы проекта «по живому», чтобы сразу видеть результат. А можно сделать из мастера отдельную ветку news и работать уже в ней (и это очень похоже на форк). В этом случае мы получим полную копию проекта, в которую можно вносить любые правки и они никак не повлияют на запущенный сайт. Мы в этой ветке пилим всё, что нужно клиенту, показываем ему результат на секретном сайте, а потом объединяем её с мастером. Это называется «смёржить бранчи».

Что такое клонирование (git clone)

Клонирование — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять.

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

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

Что значит «смёржить» (git merge)

Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.

Получается, что схема работает так:

Что такое коммит (git commit)

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

Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы.

Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.

Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.

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

Что такое пуш и пулл (git push, git pull)

Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.

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

Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.

Чем коммит отличается от пуша

Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.

Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.

Получается, последовательность действий такая:

Что дальше

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

Источник

¶ Репозиторий

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

Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создается рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).

Для того чтобы узнать как создать репозиторий перейдите по ссылке:
git quickstart

¶ Зеркалирование репозиториев

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

Зеркальное отображение репозитория полезно, когда вы хотите использовать репозиторий вне GitLab.

GitLab поддерживает два типа зеркалирования репозитория:

При обновлении зеркального репозитория все новые ветки, теги и фиксации будут отображаться в ленте активности проекта.

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

¶ Случаи применения

Ниже приведены некоторые возможные варианты использования зеркального отображения репозитория:

¶ Отправка в удаленный репозиторий

Для существующего проекта вы можете настроить push-зеркалирование следующим образом:

¶ Что значит сохранить расходящиеся ссылки

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

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

Изменения, отправленные в файлы в репозитории, автоматически отправляются на удаленное зеркало по крайней мере:

Вы можете отправлять только защищенные ветки из GitLab в удаленный репозиторий.

В случае разветвленной ветви вы увидите ошибку, указанную в разделе «Mirroring repositories».

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

¶ Извлечение из удаленного репозитория

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

Это полезно, когда интересующий вас репозиторий находится на другом сервере, и вы хотите иметь возможность просматривать его содержимое и его активность с помощью знакомого интерфейса GitLab.

Чтобы настроить вытягивание зеркала для существующего проекта:

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

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

Для более подробной информации можно перейти по ссылке: Repository mirroring

¶ Коммит

Любые файлы, созданные или измененные вами и для которых вы не выполнили git add после редактирования, не войдут в ваш коммит. Они останутся измененными файлами на вашем диске.

Пример работы с коммитом можно посмотреть в разделе «Быстрый старт в Git»(в блоке «Что такое коммит?»).

¶ Если коммиты с другой почты

В статистике Git, размещенной в Личном кабинете, учитываются коммиты, сделанные только с почты с доменом @miem.hse.ru.

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

Для этого выполните следующие действия:

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

¶ Просмотр истории коммитов

Если вы запустите команду git log в папке склонированного проекта, то увидите следующий вывод:

По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке: последние коммиты находятся вверху.

¶ Поиск коммитов по разным критериям

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

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

¶ Разница между автором и коммитером.

Автор – это человек, изначально сделавший работу, а коммитер – это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника: вы как автор и основной член команды как коммитер.

¶ Ограничение вывода

Опции для ограничения вывода команды git log вы можете увидеть эти и другие распространенные опции.

¶ Ветки

Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию имя основной ветки в Git — master.

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

¶ Создание новой ветки

Что происходит при создании ветки? Создаётся новый указатель для дальнейшего перемещения.

Это тоже самое что и:
$ git branch testing
$ git checkout testing
Здесь мы сначала создали ветку, затем перешли на нее.

¶ Работа с веткой master

¶ Как сделать merge request

Merge request позволяет перед коммитом в master ветку отправить внесенные изменения другим разработчикам проекта. Это аналог pull request в git. Merge request позволяет предотвратить внесение некорректных изменений, которые сломают проект.

Для начала создадим и перейдем на ветку, с которой будем работать:

Далее нужно перейти в настройки вашего проекта, в боковой меню нажмите на «Merge Requests«.

В открывшемся окне нажмите на кнопку «New Merge Request» для создания нового запроса на слияния одной ветки с другой.

В разделе выберите ветку, из которой хотите добавить изменения (в нашем случае development). В качестве «Target branch» выберите master.

Затем нажмите на кнопку «Compare branches and continue«.

Если не возникло конфликтов, на новой странице задайте заголовок, описание и в поле Assignee выберите своего руководителя.

Рекомендуем вам делать при слиянии веток сквош: объединять коммиты. Это помогает избежать путаницы и длинного списка коммитов. Для этого просто поставьте галочку около пункта «Squash commits when merge request is accepted». Далее нажмите на «Merge».

Подробнее о правильной работе с GitFlow можно прочитать здесь:
Модель ветвления Gitflow

Источник

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. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.

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

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

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

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

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

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

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

Источник