Çekme isteği ve Birleştirme isteği

468

Bir Çekme isteği ile Birleştirme isteği arasındaki fark nedir?

Github'da bir Çekme İsteği ve örneğin GitLab'da bir Birleştirme İsteği ... Bunların ikisi arasında bir fark var mı?

git github gitlab

— Pacane
kaynak

766

GitLab'ın "birleştirme isteği" özelliği, GitHub'ın "çekme isteği" özelliğine eşdeğerdir . Her ikisi de değişiklikleri başka bir daldan veya çataldan dalınıza çekmenin ve mevcut kodunuzla birleştirmenin bir yoludur. Kod inceleme ve değişiklik yönetimi için kullanışlı araçlardır.

GitLab'ın bir makalesinde , özelliğin adlandırılmasındaki farklılıklar tartışılmaktadır:

Birleştirme veya çekme istekleri bir git yönetimi uygulamasında oluşturulur ve atanan bir kişiden iki dalı birleştirmesini ister. GitHub ve Bitbucket gibi araçlar, ilk manuel işlem özellik dalını çekmek olacağı için ad çekme isteğini seçer. GitLab ve Gitorious gibi araçlar, birleştirici tarafından istenen son eylem olduğundan ad birleştirme isteğini seçer. Bu yazıda birleştirme istekleri olarak bahsedeceğiz.

"Birleştirme isteği" git mergekomutuyla karıştırılmamalıdır . "Çekme isteği" git pullkomutuyla da karıştırılmamalıdır . Her iki gitkomut da hem çekme isteklerinde hem de birleştirme isteklerinde perde arkasında kullanılır, ancak bir birleştirme / çekme isteği yalnızca bu iki komuttan çok daha geniş bir konuyu ifade eder.

— gilly3
kaynak

1

GitHub, çekme isteği yapıldığında bir ara / geçici dal (görünmez) oluşturur mu?

— Robert Koritnik

1

@stevemao onlara erişebilir miyiz? Gerçekten sadece onlar üzerindeki çatışmaları çözebildiğimiz gibi mi okuyorlar?

— Robert Koritnik

11

Neyi kaçırıyorum? pull = getirme + birleştirme. Son eylem birleştirme ise, ilk eylem getirilmelidir.

— Vytenis Bivainis

61

MR her yerde daha iyi bir isim. Çekme İsteği, ilk eylem olduğunu açıklamanızı açıklayana kadar bana hiç mantıklı gelmezken, Birleştirme İsteğinin ilk kez okuduğum ikincisinin ne anlama geldiğini anladım. "merhaba, lütfen bu kodu ana dal için birleştirir misiniz?" vs "merhaba, <zımni birleştirme> için bu kodu görünmez bir şubeye götürebilir misiniz - burada açık bir kazanan var.

— Granitosaurus

7

@Granitosaurus Kabul etti. Git bir acemi olarak, çekme istekleri kesinlikle onları beklediğim değildi. Gitlab'ı kullanmaya başladığımda, birleştirme istekleri hemen anlam kazandı.

— Mark Lyons

54

Aynı özellik

Birleştirme veya çekme istekleri bir git yönetimi uygulamasında oluşturulur ve atanan bir kişiden iki dalı birleştirmesini ister. GitHub ve Bitbucket gibi araçlar, ilk manuel işlem özellik dalını çekmek olacağı için ad çekme isteğini seçer. GitLab ve Gitorious gibi araçlar, birleştirici tarafından istenen son eylem olduğundan ad birleştirme isteğini seçer. Bu yazıda birleştirme istekleri olarak bahsedeceğiz.

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

— rneves
kaynak

birleştirme yeni bir özellik ekleyen geliştiricinin sorumluluğu olmamalı mı? Bir geliştirici A, Feature_branch'a bir özellik eklerse, ana dalı alıp dalının üstüne birleştirerek tüm çakışmaları çözmeli ve birleştirme isteği oluşturmadan önce test etmelidir?

— Ciasto piekarz

2

Evet, ancak kodun ustalaşmasını sağlamak için birisinin bundan sonra yapılması gereken hızlı bir birleştirme hala var. Ve aslında, tam zamanlı geliştiricilerden oluşan bir ekipte, özellik geliştiricisinin de birleştirme yapması muhtemelen en iyisi olduğunu düşünüyorum, ancak birisinin önce PR'larını gözden geçirmesini beklemeleri yararlı olabilir.

— bdsl

21

Benim görüşüme göre, aynı faaliyet anlamına geliyor, ancak farklı bakış açılarından:

Bir düşünün, Alice, Bob'un B deposundan çatallanmış A deposu için bazı taahhütlerde bulunur.

Alice, değişikliklerini B'ye "birleştirmek" istediğinde, Bob'un bu değişiklikleri A'dan "çekmesini" ister.

Bu nedenle, Alice'in bakış açısından, bu bir "birleştirme isteği" iken, Bob bunu bir "çekme isteği" olarak görür.

— K. Sembolü
kaynak

Diğer meslektaşlarına git'in nasıl çalıştığını bildirmek için küçük bir rapor hazırladığımda örneği hatırlattı.

— Ravi Yadav

4

Çatışma yönetimi açısından ince bir fark vardır. Çatışma durumunda, Github'daki bir çekme talebi, hedef dalda birleştirme taahhüdü ile sonuçlanacaktır . Gitlab'da bir çakışma bulunduğunda, yapılan değişiklikler kaynak dalında birleştirme işleminde olacaktır .

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

"GitLab, kaynak dalda hedef dalda otomatik olarak birleştirilmemiş bir birleştirme taahhüdü oluşturarak çakışmaları giderir. Bu, birleştirme işleminin değişiklikler birleştirilmeden önce gözden geçirilmesini ve test edilmesini sağlar, böylece hedef dalda gözden geçirilmeden veya kesilmeden istenmeyen değişikliklerin önlenmesi sağlanır. yapı. "

— iclman
kaynak

3

GitLab 12.1 (Temmuz 2019) bir fark getiriyor:

" Gizli Sorunlar için Birleştirme İstekleri "

Güvenlik açıkları gibi gizli sorunları tartışırken, planlarken ve çözerken, Git deposu herkese açık olduğu için açık kaynak projelerinin verimli kalması özellikle zor olabilir.

12.1'den itibaren, ortak bir projedeki gizli sorunların, projenin özel çatalında bir birleştirme isteği oluşturmanıza yardımcı olan Gizli birleştirme isteği oluştur düğmesini kullanarak kolaylaştırılmış bir iş akışı içinde çözülmesi mümkündür.

58583 numaralı sorundan bkz . " Gizli sorunlar " .

GitHub'da benzer bir özellik var, ancak " sürdürücü güvenlik danışma " adı verilen özel bir özel çatal oluşturulmasını içeriyor .

— VonC
kaynak

0

Önceki yanıtlarda belirtildiği gibi, her ikisi de neredeyse aynı amaca hizmet eder. Şahsen git rebase ve birleştirme isteğini seviyorum (gitlab'de olduğu gibi). Birleştirme isteği eklerken özellik dalının, özellik dalı oluşturulduktan sonra ana dalda yapılan en son taahhütlerin tümünü içerdiğinden emin olarak, gözden geçiren / sürdürücüden yük alır. Rebase'i ayrıntılı olarak açıklayan çok kullanışlı bir makale: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

— Muhammed Şahbaz
kaynak