Neden git 'çekme isteği' 'push isteği' olarak adlandırılmıyor?

Bir şubeyi resmi bir depo ile birleştirmek için kullanılan terminoloji bir 'çekme talebi'dir. Değişikliklerimi resmi veri havuzuna aktarmayı talep ettiğim için bu kafa karıştırıcı.

Neden push isteği değil çekme isteği denir?

Deponuzda bir kod değişikliğiniz varsa ve onu bir hedef depoya taşımak istiyorsanız, o zaman:

• "Push", hedef depoda ( git push) bulunan değişiklikleri zorlamaktır .
• "Çekme", değişikliklerinizi orada ( git pulldiğer repodan) alacak olan hedef depodur .

Bir "çekme isteği", hedef depodan değişikliklerinizi almasını istiyor.

Değişikliklerinizi göndermenizi isteyen hedef havuz bir "push isteği" olacaktır.

Bir çekme isteği gönderdiğinizde, resmi repo sahibinden, kendi repodan bazı değişiklikler almasını istiyor (talep ediyorsunuz). Bu nedenle "çekme talebi".

tl; dr, itmeye izin verilmediğim için, repo sahibine güzel bir istekte bulunacağım, böylece çekmeye karar verdiler

Kodu bir depoya kimler iletebilir?

Herkes (muhtemelen kötü veya eğitimsiz veya bilinmeyen) gelip şunu söyleyebilseydi burada olsaydı ben sadece ana şube için itti ve tüm kod HAHAHA berbat! ?

Elbette onun bunu yapmasını istemiyorsun. Varsayılan olarak bir güvenlik ağı ayarlanmıştır, böylece hiç kimse repolarınıza itemez. Sen edebilirsiniz Ortak çalışan olarak diğerlerini ayarlamak sonra onlar itebilir. Güvendiğiniz kişilere böyle bir erişim vereceksiniz.

Dolayısıyla, ortak çalışan değilseniz ve zorlamaya çalışıyorsanız, izniniz olmadığını belirten bir hata alırsınız.

Peki diğer geliştiriciler itme izni verilmeyen bir repoya nasıl itebilirler?
Herkese erişim veremezsiniz, ancak başkalarına bir çıkış / giriş noktası vermek istersiniz, böylece 'repo sahibinden bu kodu repoya çekme talebinde bulunabilirler '. Repoyu erişilebilir hale getirerek, çatallayabilirler ... değişikliklerini kendi çatallarında yapabilirler. Değişikliklerini kendi çatallarına itin . Bir kez kendi uzaktan repolarında:

Çatallarından bir çekme isteği yaparlar ve (doğrudan itemeyeceğiniz) yukarı yönlü repo sahibinin çekme talebini birleştirip birleştirmeyeceğine karar verir.

Ayrıca yarı ilişkili bir soru okumanızı tavsiye ederim Git push tam olarak ne olur? Neden bir git itmesi tıpkı bir git birleştirme gibi düşünülmüyor?

Çekme Talebi: Ben talep etmek size çekin mayın.

Başkasının repolarına bir şeyler itmek istiyorum.

Bu konuda itme (ya da çekme) iznim yok.

Sahip / ortak çalışanların izinleri vardır. İtme kadar iyi de çekebilirler. İtemem.

Bu yüzden, benden bir çekiş yapmalarını istiyorum - dolaylı olarak onlardan itme gücümü kabul etmelerini istediğim anlamına geliyor.

Yani, itme talebi yok. Sadece çekmek için. Ve bir itmenin kabulü için.

Bu nedenle, bir 'çekme' isteği. Ve bir 'itme' talebi değil.

Bu eylemlerde anahtar olan "Talep" kelimesidir. Ayrıca "İşimi almanı istediğim bir şey var, kabul ediyor musun?" - "Çekme Talebi".

İlk başta biraz kafa karıştırıcı, ama sonunda mantıklı.

Bunu daha iyi anlamak ve sonsuza dek hatırlamak için resmetmeniz gerekir.

Büyük, canlı bir ağacı {deponuz olarak} hayal edin. Ağaç, bir dalı içine sokmanız veya içine yeni bir parça eklemeniz için çok sağlamdır {yeni bir dal oluşturmayı sembolize eder veya içine kod itersiniz}, bunun yerine ağaçtan bir dalı gövdeye çekmesini veya sizden değişiklikler.

“Çekme talepleri” terimi dağıtılmış niteliktedir. Değişikliklerinizi sadece depoya göndermek yerine (örneğin Subversion gibi merkezi bir depoda yaptığınız gibi) değişikliklerinizi ayrı ayrı yayınlıyorsunuz ve bakım sahibinden değişikliklerinizi yapmasını istersiniz. Koruyucu daha sonra değişiklikleri gözden geçirebilir ve söz konusu çekme işlemini yapabilir.

Yani temelde katkıda bulunmak istediğiniz repo yazma erişimi olan çocuklar "repo" çekme "için" talep ".

Çekme istekleri, GitHub'daki bir depoda bir şubeye aktardığınız değişiklikleri başkalarına anlatmanıza olanak tanır. Bir çekme isteği açıldıktan sonra, olası değişiklikleri ortak çalışanlarla tartışıp inceleyebilir ve değişiklikleriniz temel şubeye birleştirilmeden önce takip taahhütleri ekleyebilirsiniz. Github Açıklaması

Bunu düşünmek istiyorum çünkü onun saçma terminolojisini düşünüyorum ben size PUSH şey istiyoruz ve madenin ilavelerine çekmeye başkası soran tersi mengenesi düşünmediğini. Bu nedenle PUSH REQ olarak değiştirilmelidir. çünkü ben aktif kısımım. Ok benimle başlayarak diğer tarafa gider, diğer uçtaki Goofy'e değil. BENİM NACİZANE FİKRİME GÖRE.

Bu şekilde düşün. Yerel depo vs Uzak depo.

• Ne zaman itin Yerel'den. ( git push) - diğer bir deyişle, Uzaktan depo edilir Çekme sizden kodları (Yerel).

Bir şey istiyorsun. O zaman kendinize sorun,

• Uzak depo Sizden kodları çekmek istiyor musunuz ? - Çekme Talebi.

Korkarım bu cevapların çoğunda 'talep çekme' ne anlama geliyor? veya 'Push request' ne anlama gelir? OP sorusundan ziyade: Neden push talebi değil çekme talebi denir?

Normalde bu tür bir soru değiştirme kabul edilebilir, ancak bu durumda OP'nin bu değiştirme sorularının cevaplarını bildiği açıktır, bu nedenle cevaplamak çok yararlı değildir.

Sadece GitHub'da bu terimi kullanan insanlar kesin olarak biliyor. Bununla birlikte, bu terminolojik seçimin "dışarıdan havuza gelen değişiklikler" olgusu ile ilgili aşağıdaki bakış açısına benzer bir şey yansıttığı görülmektedir: Bakımcı eylemi gerçekleştirir (çeker) .

Bununla birlikte, bir talep aynı zamanda bir eylemdir ve bu eylemin yapıcısı sürdürücü değil, daha çok (daha fazla eylem yapan, yani iş yapan) gönderen kişidir. Böylece 'çekme talebi' terimi , ajanın kim olduğu konusunda karışıklık yaratır . Sonuçta karışıklık, bir talebin özyinelemeli yapısı nedeniyle ortaya çıkar: Talep, hem birincil aracı tarafından yapılan bir eylem hem de ikinci aracı tarafından gelecekte yapılacak bir eylem talebidir.

Durum, "evimizi inşa ettik" ("evimizi inşa etmek için başka birine para verdik" yerine kullanılan) gibi yaygın olan dilbilimsel yapılara oldukça benzer, birincil eylemin sorumluluğu bariz orijinal ajandan yönetsel sosyal rolü yerine getiren ikincil bir temsilci.

Buradan, terminolojik seçimin nedeninin yönetimsel çalışmanın birinci sınıf emek olduğu görüşünün meşrulaştırılması olduğu sonucuna varılabilir . Ayrıca, bu terminolojik seçim hakkındaki karışıklığın nedeni, yönetici olmayan işçilerin doğal olarak farklı bir bakış açısına sahip olmaları olabilir.