Запрос на вытягивание против запроса на слияние


468

В чем разница между запросом Pull и запросом на слияние.

В Github это запрос на извлечение, а в GitLab, например, это запрос на слияние ... Есть ли разница между ними обоими?

Ответы:


766

Функция GitLab «запрос на слияние» эквивалентна функции GitHub «запрос на извлечение» . И то, и другое - это способ перенести изменения из другой ветки или ветки в вашу ветку и объединить изменения с существующим кодом. Они являются полезными инструментами для проверки кода и управления изменениями.

В статье из GitLab обсуждаются различия в именовании этой функции:

Запросы на слияние или извлечение создаются в приложении управления git и просят назначенное лицо объединить две ветви. Такие инструменты, как GitHub и Bitbucket, выбирают запрос извлечения имени, поскольку первым ручным действием было бы извлечение ветви функции. Такие инструменты, как GitLab и Gitorious, выбирают запрос на слияние имен, поскольку это последнее действие, запрошенное у правопреемника. В этой статье мы будем называть их запросами на слияние.

«Запрос на слияние» не следует путать с git mergeкомандой. Не следует путать «запрос на извлечение» с git pullкомандой. Обе gitкоманды используются за кулисами как в запросах на извлечение, так и в запросах на слияние, но запрос на слияние / извлечение относится к гораздо более широкой теме, чем только эти две команды.


1
Создает ли GitHub промежуточную / временную ветвь (невидимую) при выполнении запроса на удаление?
Роберт Коритник

1
@stevemao мы можем получить к ним доступ? Они действительно только для чтения, так как мы можем разрешить конфликты на них?
Роберт Коритник

11
Что мне не хватает? тянуть = получить + объединить. Если последним действием является слияние, то первое действие должно быть извлечено.
Витенис Бивайнис

61
MR просто лучшее имя вокруг. Запрос на извлечение никогда не имел для меня смысла, пока я не прочитал ваше объяснение того, что это первое действие, и понял, что означает запрос на слияние, когда прочитал его впервые "привет, не могли бы вы объединить этот код с основной веткой?" vs "привет, не могли бы вы вытащить этот код в невидимую ветку для <подразумеваемого слияния>" - здесь есть явный победитель.
Granitosaurus

7
@Granitosaurus Согласен. Будучи новичком в git, запросы на получение запросов были совершенно не такими, как я ожидал. Когда я начал использовать Gitlab, запросы на слияние имели смысл сразу.
Марк Лайонс

54

Они одинаковые

Запросы на слияние или извлечение создаются в приложении управления git и просят назначенное лицо объединить две ветви. Такие инструменты, как GitHub и Bitbucket, выбирают запрос извлечения имени, поскольку первым ручным действием было бы извлечение ветви функции. Такие инструменты, как GitLab и Gitorious, выбирают запрос на слияние имен, поскольку это последнее действие, запрошенное у правопреемника. В этой статье мы будем называть их запросами на слияние.

- https://about.gitlab.com/2014/09/29/gitlab-flow/


не должно ли объединение быть ответственностью разработчика, который добавляет новую функцию? если разработчик А добавляет функцию в feature_branch, он должен взять основную ветку и объединить ее поверх своей ветви, разрешить все конфликты и проверить ее перед созданием запроса на слияние?
Ciasto piekarz

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

21

На мой взгляд, они означают одну и ту же деятельность, но с разных точек зрения:

Подумайте об этом, Алиса делает некоторые коммиты в хранилище A, которое было разветвлено из хранилища Боба B.

Когда Алиса хочет «объединить» свои изменения с B, она фактически хочет, чтобы Боб «вытянул» эти изменения из A.

Следовательно, с точки зрения Алисы, это «запрос на слияние», а Боб рассматривает его как «запрос на извлечение».


Это напомнило мне пример, когда я сделал небольшой отчет, чтобы другие коллеги знали, как работает git.
Рави Ядав

4

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

См. Https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html.

«GitLab разрешает конфликты путем создания коммита слияния в исходной ветке, который не объединяется автоматически с целевой ветвью. Это позволяет коммиту слияния быть проверенным и протестированным до слияния изменений, предотвращая попадание непреднамеренных изменений в целевую ветвь без проверки или прерывания сборка. "


3

GitLab 12.1 (июль 2019) вводит разницу:

« Слияние запросов по конфиденциальным вопросам »

При обсуждении, планировании и решении конфиденциальных вопросов, таких как уязвимости безопасности, для проектов с открытым исходным кодом может быть особенно сложно оставаться эффективными, поскольку репозиторий Git является открытым.

https://about.gitlab.com/images/12_1/mr-confidential.png

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

См. « Конфиденциальные вопросы » из номера 58583 .

Аналогичная функция существует в GitHub, но включает в себя создание специального частного ветвления, называемого « рекомендация по безопасности для сопровождающего ».


0

Как уже упоминалось в предыдущих ответах, оба служат почти одной цели. Лично мне нравится git rebase и запрос на слияние (как в gitlab). Это берет на себя нагрузку на рецензента / сопровождающего, обеспечивая, чтобы при добавлении запроса на слияние ветвь функций включала в себя все последние коммиты, выполненные в основной ветке после создания ветви функций. Вот очень полезная статья, подробно объясняющая ребаз: https://git-scm.com/book/en/v2/Git-Branching-Rebasing.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.