Что такое merge request в 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. Урок 24.
Мердж-реквесты и код-ревью
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое мердж-реквест?
Зачем нужны мердж-реквесты?
В первую очередь они нужны при работе в команде для проведения код-ревью. Чтобы коллеги увидели новый код и как минимум его просмотрели и оставили замечания или вопросы
Как правильно: merge request или pull request?
Как проходит процедура мердж-реквеста
Немного о markdown
Markdown позволяет форматировать текст: задавать заголовки, списки, цитаты, вставлять ссылки и картинки и даже форматировать код. Насчет кода, возможно, для приграммиста это самая удобная фишка markdown, так как используется достаточно часто
Изучается markdown быстро, разметка очень простая. Вот пример оформления списка, используются звездочки
А вот пример оформления кода, используются апострофы
После этого ваш текст красиво отформатируется, можете попробовать в любом markdown онлайн-редакторе, например, dillinger.io/
Совет от автора
Немного о код ревью
Это отдельная большая тема и git она не касается. Поэтому приведу только кратко причины проводить код ревью
Вопросы на код ревью могут быть совершенно разные и на разные темы. Это всего лишь краткий перечень плюсов от код ревью
Как оповестить коллег о новом мердж-реквесте
Здесь разные варианты, зависит от договоренностей в команде.
Главное договориться как будет удобнее всем в вашей команде
Кто принимает мердж-реквесты
Здесь тоже могут быть разные варианты:
Немного о работе в команде
Getting started with merge requests
A merge request (MR) is the basis of GitLab as a code collaboration and version control.
When working in a Git-based platform, you can use branching strategies to collaborate on code.
A repository is composed by its default branch, which contains the major version of the codebase, from which you create minor branches, also called feature branches, to propose changes to the codebase without introducing them directly into the major version of the codebase.
Branching is especially important when collaborating with others, avoiding changes to be pushed directly to the default branch without prior reviews, tests, and approvals.
When you create a new feature branch, change the files, and push it to GitLab, you have the option to create a merge request, which is essentially a request to merge one branch into another.
The branch you added your changes into is called source branch while the branch you request to merge your changes into is called target branch.
The target branch can be the default or any other branch, depending on the branching strategies you choose.
In a merge request, beyond visualizing the differences between the original content and your proposed changes, you can execute a significant number of tasks before concluding your work and merging the merge request.
You can watch our GitLab Flow video for a quick overview of working with merge requests.
How to create a merge request
Learn the various ways to create a merge request.
What you can do with merge requests
Assignee
Choose an assignee to designate someone as the person responsible for the first review of the merge request. Open the drop down box to search for the user you wish to assign, and the merge request is added to their assigned merge request list.
Multiple assignees
Moved to GitLab Premium in 13.9
Multiple people often review merge requests at the same time. GitLab allows you to have multiple assignees for merge requests to indicate everyone that is reviewing or accountable for it.
Similarly, assignees are removed by deselecting them from the same dropdown menu.
Reviewer
The merge request Reviewers feature enables you to request a review of your work, and see the status of the review. Reviewers help distinguish the roles of the users involved in the merge request. In comparison to an Assignee, who is directly responsible for creating or merging a merge request, a Reviewer is a team member who may only be involved in one aspect of the merge request, such as a peer review.
To request a review of a merge request, expand the Reviewers select box in the right-hand sidebar. Search for the users you want to request a review from. When selected, GitLab creates a to-do list item for each reviewer.
Merge requests to close issues
If the issue is confidential, you may want to use a different workflow for merge requests for confidential issues to prevent confidential information from being exposed.
Deleting the source branch
When creating a merge request, select the Delete source branch when merge request accepted option, and the source branch is deleted when the merge request is merged. To make this option enabled by default for all new merge requests, enable it in the project’s settings.
This option is also visible in an existing merge request next to the merge request button and can be selected or deselected before merging. It is only visible to users with the Maintainer role in the source project.
If the user viewing the merge request does not have the correct permissions to delete the source branch and the source branch is set for deletion, the merge request widget displays the Deletes source branch text.
Branch retargeting on merge
The feature today works only on merge. Clicking the Remove source branch button after the merge request was merged will not automatically retarget a merge request. This improvement is tracked as a follow-up.
Как создать запрос на слияние (Merge request) в Gitlab
В данной статье рассмотрим пример как влить свои изменения в чужую ветку Gitlab.
Предварительные действия:
Все действия будут показаны на примере среды разработки Idea Intellij в которой работают тестировщики и пишут тест-кейсы на java. Далее каждый тестировщик отправляет изменения из своей ветки в конечную ветку develop.
Idea Intellij удобна тем, что там имеется встроенный инструмент GIT, т.е. не приходится отдельно работать в менеджере git или в консоли git bash.
Таким образом мы создадим новую ветку с именем «new_branch» на основании ветки «develop».
02 Работаем с новой веткой «new_branch», делаем нужные изменения, коммитим их, отправляем (git push) в ветку «new_branch». При этом локальная ветка«new_branch» созданная на основании «develop» создастся не только локально, но и на сервере репозитория.
03 Создадим запрос на слияние «Merge request» с веткой «develop» коммитов из ветки «new_branch». Для этого переходим на сайт Gitlab и ищем в меню кнопку 
и на новой открывшейся странице найдем кнопку создания запроса 
выберем ветки слияния:
1. В форме «Source branch» выбрать ветку, из которой слить изменения (коммиты).
2. В форме «Target branch» выбрать ветку, в которую нужно влить изменения (коммиты).
3. Нажать кнопку «Compare branches and continue».
04 Далее добавить описание запроса на слияние:
05 Далее зарегистрировать запрос на слияние:
06 Создан новый запрос на слияние:
после создания осуществляется переход на страницу запроса
Запрос можно редактировать, нажав кнопку 
.
07 Одобрение и слияние веток:
Хозяину ветки «develop» остается проверить коммиты, «Одобрить» и принять через «Слияние» наши изменения из «new_branch»:
При возникновении конфликтов при слиянии веток, хозяину «develop» нужно их разрешить самостоятельно или отправить инициатору изменений «new_branch» для разрешения конфликтов на его стороне.
GitLabWork 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. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.
Больше мерж-реквестов
Для набора изменений, затронувшего несколько модулей, если изменения в этом модуле не совсем тривиальны и нуждаются в ревью (см. ниже раздел «Когда направлять мерж-реквест, а когда нет»), создаётся по одному мерж-реквесту на каждый модуль.
Имена веток во всех модулях должны совпадать. Для навигации между ними в описании добавляются перекрёстные ссылки.
Кто принимает мерж-реквест
Мерж-реквест должен быть одобрен хотя бы одним разработчиком, который не принимал непосредственного участия в написании кода этого изменения
Ревьюверу следует обращать внимание на:
Комментарии и замечания должны находиться непосредственно в данном мерж-реквесте.
Исправления замечаний делаются в той же ветке и видны в мерж-реквесте.