Что такое merge request
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. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.
Больше мерж-реквестов
Для набора изменений, затронувшего несколько модулей, если изменения в этом модуле не совсем тривиальны и нуждаются в ревью (см. ниже раздел «Когда направлять мерж-реквест, а когда нет»), создаётся по одному мерж-реквесту на каждый модуль.
Имена веток во всех модулях должны совпадать. Для навигации между ними в описании добавляются перекрёстные ссылки.
Кто принимает мерж-реквест
Мерж-реквест должен быть одобрен хотя бы одним разработчиком, который не принимал непосредственного участия в написании кода этого изменения
Ревьюверу следует обращать внимание на:
Комментарии и замечания должны находиться непосредственно в данном мерж-реквесте.
Исправления замечаний делаются в той же ветке и видны в мерж-реквесте.
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 для отмены.
В чем отличие 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.12.22.41046
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Как создать запрос на слияние (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» для разрешения конфликтов на его стороне.
Creating merge requests
There are many different ways to create a merge request.
From the merge request list
From an issue
When you add, edit, or upload a file
When you create a branch
When you use Git commands locally
You can create a merge request by running Git commands on your local machine.
Create, edit, or delete files. The stage and commit them:
GitLab prompts you with a direct link for creating a merge request:
Copy the link and paste it in your browser.
You can add other flags to commands when pushing through the command line to reduce the need for editing merge requests manually through the UI.
When you work in a fork
After your work is merged, if you don’t intend to make any other contributions to the upstream project, you can unlink your fork from its upstream project. Go to Settings > Advanced Settings and remove the forking relationship.
By sending an email
You can create a merge request by sending an email message to GitLab. The merge request target branch is the project’s default branch.
A merge request is created.
Add attachments when creating a merge request by email
The combined size of the patches can be 2 MB.
If the source branch from the subject does not exist, it is created from the repository’s HEAD or the specified target branch. You can specify the target branch by using the /target_branch quick action. If the source branch already exists, the patches are applied on top of it.