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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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