Запрос на вытягивание против запроса на слияние
Ответы:
Функция GitLab «запрос на слияние» эквивалентна функции GitHub «запрос на извлечение» . И то, и другое - это способ перенести изменения из другой ветки или ветки в вашу ветку и объединить изменения с существующим кодом. Они являются полезными инструментами для проверки кода и управления изменениями.
В статье из GitLab обсуждаются различия в именовании этой функции:
Запросы на слияние или извлечение создаются в приложении управления git и просят назначенное лицо объединить две ветви. Такие инструменты, как GitHub и Bitbucket, выбирают запрос извлечения имени, поскольку первым ручным действием было бы извлечение ветви функции. Такие инструменты, как GitLab и Gitorious, выбирают запрос на слияние имен, поскольку это последнее действие, запрошенное у правопреемника. В этой статье мы будем называть их запросами на слияние.
«Запрос на слияние» не следует путать с git mergeкомандой. Не следует путать «запрос на извлечение» с git pullкомандой. Обе gitкоманды используются за кулисами как в запросах на извлечение, так и в запросах на слияние, но запрос на слияние / извлечение относится к гораздо более широкой теме, чем только эти две команды.
Они одинаковые
Запросы на слияние или извлечение создаются в приложении управления git и просят назначенное лицо объединить две ветви. Такие инструменты, как GitHub и Bitbucket, выбирают запрос извлечения имени, поскольку первым ручным действием было бы извлечение ветви функции. Такие инструменты, как GitLab и Gitorious, выбирают запрос на слияние имен, поскольку это последнее действие, запрошенное у правопреемника. В этой статье мы будем называть их запросами на слияние.
На мой взгляд, они означают одну и ту же деятельность, но с разных точек зрения:
Подумайте об этом, Алиса делает некоторые коммиты в хранилище 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.