“Git remote add…” ve “git push origin master” nedir?

Oldukça sık, Git ve Rails sihir gibi görünüyor ... Rails 3 Eğitim kitabının ilk bölümünde olduğu gibi , Git hakkında konuşuyor:

git remote add origin git@github.com:peter/first_app.git
git push origin master

ve neredeyse ne olduklarını çok fazla söylemeden "sadece çalışır" diyor ve dallanma hakkında konuşmaya başlıyor. İnternette arama yapmak, git remote add"kısa ad" eklemek gibi bir şey olduğunu gösterir originve URL'ye takma ad gibi herhangi bir ad da olabilir. Ve originuzak repo'nun işaret ettiği olağan yoldur. ( http://git-scm.com/book/en/Git-Basics-Working-with-Remotes içinde "Uzak Depo Ekleme" altında)

URL neden olmasa git://git@github.com/peter/first_app.gitda diğer sözdiziminde - sözdizimi nedir? Neden bitmeli .git? .gitSonunda kullanmamaya çalıştım ve çok işe yarıyor. Değilse .git, başka ne olabilir? gitİçinde git@github.comgit sunucusunda bir kullanıcı hesabı gibi görünüyor?

Ayrıca, kullanmak için neden bu kadar ayrıntılı olması gerekiyor git push origin master? Varsayılan, başlangıç ​​noktası ve ana öğe olamaz mı? İlk kez, origin mastergerekli olduğunu gördüm , ancak küçük bir düzenleme ve taahhütten sonra git push, tüm ihtiyaç (ihtiyaç yok origin master). Neler olduğunu bilen biri bazı ayrıntılar verebilir mi?

Bazen açıklama yapmadan çok fazla sihir gibi hissediyor ... ve bazen onu kullanan kişi kendinden emin ve neden sorulduğunda, açıklayamıyor ve "bu şekilde" gibi bir şeyle yanıt veriyor. Bazen çok pratik ve pragmatiktir. Pratik olmak kötü değil, ama neler olduğunu bilmemek için muhtemelen pratik değildir.

gitUNIX gibidir. Kullanıcı dostu ama arkadaşları hakkında seçici. Kabuk boru hattı kadar güçlü ve kullanıcı dostu.

Bununla birlikte, paradigmalarını ve kavramlarını anladıktan sonra, UNIX komut satırı araçlarından beklediğim aynı zenlike berraklığına sahip. Çevrimiçi olarak sunulan birçok iyi git öğreticisinden birini okumak için biraz zaman ayırmayı düşünmelisiniz. Pro Git kitabı başlamak için iyi bir yerdir.

İlk sorunuzu cevaplamak için.

1. Nedir git remote add ...

   Muhtemelen bildiğiniz gibi git, dağıtılmış bir sürüm kontrol sistemidir. Çoğu işlem yerel olarak yapılır. Dış dünya ile iletişim kurmak için gitdenilen şeyi kullanır remotes. Bunlar, yerel diskinizdeki pushdeğişikliklerin (diğer kişilerin görebilmesi için) ya pullda (başkalarının değişikliklerini alabilmeniz için) değiştirebileceğiniz depolardır . Komut git remote add origin git@github.com:peter/first_app.gitadı verilen yeni bir uzaktan oluşturur originbulunan git@github.com:peter/first_app.git. Bunu yaptıktan sonra, push komutlarınızda originURL'nin tamamını yazmak yerine zorlayabilirsiniz .

2. Nedir git push origin master

   Bu, "adlı masteruzak dalda yer alan taahhütleri" adlı uzaktan kumandaya aktar origin" yazan bir komuttur . Bu yapıldıktan sonra, orijini ile en son senkronize ettiğiniz tüm öğeler uzak depoya gönderilir ve diğer kişiler bunları orada görebilir.

Şimdi nakliyeler (yani git://) hakkında. Uzaktan veri havuzu URL'leri birçok türleri (olabilir file://, https://vs.). Git, izinler ve diğer şeylerle ilgilenmek için taşıma tarafından sağlanan kimlik doğrulama mekanizmasına güvenir. Bu, file://URL'ler için UNIX dosya izinleri, vb. git://Olacağı anlamına gelir . Şema, git'den kendi git aktarım protokolünü kullanmasını istiyor, bu da git değişiklik kümelerini göndermek için optimize edildi. Tam URL'ye gelince, github'un gitsunucusunu kurma şekli budur .

Şimdi ayrıntı. Yazdığınız komut genel komuttur. Git'e " masterburada adı geçen şube denilen foouzaktan kumandanın yerel aynasıdır " gibi bir şey söylemek mümkündür bar. Git konuşmasında, bu master parça anlamına gelir bar/foo. İlk kez klonladığınızda, ana dalın kökeni izlemek için yerel ana ayarlı bir şube masterve bir uzaktan kumanda origin(klonlandığınız yer) denir . Bu ayarlandıktan sonra, basitçe söyleyebilir git pushve yapacak. Daha uzun komut, ihtiyacınız olması durumunda kullanılabilir (örn git push. Resmi halka açık repoya itilebilir ve git push review masterekibinizin kodu incelemek için kullandığı ayrı bir uzaktan kumandaya itmek için kullanılabilir). Şunu kullanarak şubenizi bir izleme dalı olacak şekilde ayarlayabilirsiniz--set-upstreamgit branchkomut seçeneği .

Git'in (kullandığım diğer uygulamaların aksine) içten dışa daha iyi anlaşıldığını hissettim. Verilerin depo içinde nasıl saklandığını ve korunduğunu anladıktan sonra, komutlar ve bunların ne yaptıkları çok net hale gelir. Birçok gitkullanıcı arasında bazı seçkincilik olduğunu kabul ediyorum, ancak UNIX kullanıcılarıyla bir zamanlar bunu buldum ve sistemi öğrenmek için onları geçmeye değerdi. İyi şanslar!

Güncelleme: şu anda kabul edilen cevabın , davranışıyla ilgili yaygın bir yanlış anlama sürdürdüğüne dikkat edin; bu, git pushişaret eden bir yoruma rağmen düzeltilmemiştir.

Uzaktan kumandaların ne olduğu hakkındaki özetiniz - bir deponun URL'sinin takma adı gibi - doğrudur.

Peki URL neden gitmiyor: //git@github.com/peter/first_app.git ama diğer sözdiziminde - bu sözdizimi nedir? Neden .git ile bitmeli? Sonunda .git kullanmamaya çalıştım ve çok işe yarıyor. Eğer değilse .git, başka ne olabilir? Başlangıçtaki git git sunucusunda bir kullanıcı hesabı gibi görünüyor?

Bahsettiğiniz iki URL, iki farklı taşıma protokolünün kullanılması gerektiğini gösterir. Başlangıç ​​olarak git://, genellikle yalnızca depolara salt okunur erişim için kullanılan git protokolü kullanılır. Diğeri, git@github.com:peter/first_app.gitSSH üzerinden bir depoya erişimi belirtmenin farklı yollarından biridir - bu, belgelerde açıklanan "scp stili sözdizimidir" . Scp stili sözdizimindeki kullanıcı adının gitGitHub'ın tanımlayıcı kullanıcılarla ilgilenme biçimi olmasından kaynaklanır - esasen kullanıcı adı yok sayılır ve kullanıcı kimlik doğrulaması için kullandıkları SSH anahtar çiftine göre tanımlanır.

Ayrıntılara gelince git push origin master, ilk itmeden sonra sadece yapabileceğinizi fark ettiniz git push. Bunun nedeni, hatırlanması zor olan ancak genellikle yardımcı olan bir dizi varsayılan değerdir :)

• Hiçbir uzaktan kumanda belirtilmezse, geçerli dal için yapılandırılmış olan uzaktan kumanda ( remote.master.urlsizin durumunuzda) kullanılır. Bu ayarlanmadıysa originkullanılır.
• Herhangi bir "refspec" (ör master. master:my-experiment, Vb.) Belirtilmemişse, git varsayılan olarak uzaktan kumandadaki bir dalla aynı ada sahip her yerel dalı iter. masterDeponuzla uzak olan arasında ortak olarak adlandırılan bir şubeniz varsa , bu master, uzaktan kumandanıza itmekle aynı olacaktır master.

Şahsen, birçok konu dalına (ve genellikle birkaç uzaktan kumandaya) sahip olduğum için her zaman formu kullanıyorum:

git push origin master

... yanlışlıkla diğer dalları itmekten kaçınmak için.

Diğer yanıtlar birinde yorumlarınızı cevap olarak, bu sanki bana sesler vardır çok etkili bir şekilde yukarıdan aşağıya bir şekilde Git öğrenmeye - Eğer varsayılan çalıştığını fark ettik, ve soru neden soruyor;) To daha ciddi ol, git canesas olarak SVN kadar basit kullanılmalıdır, ancak uzaktan kumandalar ve dallar hakkında biraz bilgi sahibi olmak, onu daha esnek bir şekilde kullanabileceğiniz anlamına gelir ve bu, daha iyi çalışma şeklinizi gerçekten değiştirebilir. Bir dönem dersiyle ilgili konuşmanız beni Scott Chacon'un bir podcast röportajında ​​söylediği bir şey hakkında düşünmemi sağlıyor - öğrencilere bilgisayar bilimi ve yazılım mühendisliğindeki her türlü temel araç hakkında öğretiliyor, ancak nadiren sürüm kontrolü. Git ve Mercurial gibi dağıtılmış versiyon kontrol sistemleri artık çok önemli ve çok esnek, insanlara iyi bir temel vermek için üzerlerinde dersler vermeye değer.

Benim görüşüme göre git, bu öğrenme eğrisi kesinlikle buna değer - birçok konu dalı ile çalışmak, onları kolayca birleştirmek ve sisteme güven duyduğunuzda onları farklı havuzlar arasında itmek ve çekmek fevkalade faydalıdır. Bu sadece talihsiz bir durum:

• Git için birincil belgeleri yeni gelenler için ayrıştırmak çok zordur. (Her ne kadar git sorusu için Google'da olursanız, bugünlerde yararlı öğretici materyallerin (veya Yığın Taşması cevapları :)) ortaya çıktığını iddia etsem de.)
• Git'te şu anda değiştirilmesi zor olan birkaç garip davranış var, çünkü birçok komut dosyası bunlara güvenebilir, ancak insanlar için kafa karıştırıcıdır.

Uzak bir repo eklemek için sözdizimine bir göz atın.

git remote add origin <url_of_remote repository>

Misal:

git remote add origin git@github.com:peter/first_app.git

Komutu inceleyelim:

git remote , git depolarınızı barındırmak üzere Central sunucularınızı yönetmek için kullanılır.

Belki de merkezi depo materyalleriniz için Github kullanıyor olabilirsiniz . Size bir örnek vereceğim ve git remote add origin komutunu açıklayacağım

Git depoları için merkezi sunucular için GitHub ve BitBucket ile çalıştığımı ve ilk uygulama projem için her iki web sitesinde de depolar oluşturduğumu varsayalım .

Şimdi değişiklikleri her iki git sunucularına da itmek istersem, git bu merkezi depolara nasıl ulaşacağımı söylemem gerekecek. Bunları eklemem gerekecek,

GitHub için

git remote add gh_origin https://github.com/user/first-app-git.git

Ve BitBucket için

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

(Değişken olarak adlandırmak benim için kolay olduğu için) iki değişken kullandım gh_origin (gh FOR GITHUB) ve bb_origin (bb için BITBUCKET) sadece istediğimiz her şeyi anlatabileceğimizi açıklamak için.

Şimdi bazı değişiklikler yaptıktan sonra, diğer kullanıcıların bu değişiklikleri görebilmesi için tüm bu değişiklikleri merkezi depolara göndermek (itmek) gerekecek. Ben de ararım

GitHub'a aktarılıyor

git push gh_origin master

BitBucket'e aktarılıyor

git push bb_origin master

gh_origin https://github.com/user/first-app-git.git değerini tutuyor ve bb_origin https değerini tutuyor : //user@bitbucket.org/user/first-app-git.git

Bu iki değişken hayatımı kolaylaştırıyor

ne zaman kod değişiklikleri göndermek gerektiğinde ben hatırlamak veya aynı URL yazmak yerine bu kelimeleri kullanmanız gerekir.

Çoğu zaman , örneğin Github veya BitBucket gibi tek bir merkezi havuzla uğraşacağınız için, orijinden başka bir şey görmezsiniz.

1. .gitDepo adının sonuna sadece bir kuralıdır. Tipik olarak, git sunucularında depolar adlı dizinlerde tutulur project.git. Git istemcisi ve protokolü project.gityalnızca ne zaman projectbelirtildiğini test ederek bu kuralı onurlandırır .

2. git://git@github.com/peter/first_app.gitgeçerli bir git url değil. git depoları burada belirtilen çeşitli url şemaları ile tanımlanabilir ve erişilebilir . git@github.com:peter/first_app.git olan ssho sayfada belirtilen URL.

3. gitesnektir. Yerel şubenizi herhangi bir deponun neredeyse her şubesine karşı izlemenize olanak tanır. İken master(yerel varsayılan dalı) izleme origin/master(uzaktan varsayılan dalı) popüler bir durumdur, bu evrensel değildir. Birçok kez bunu yapmak istemeyebilirsiniz. Bu yüzden birincisi git pushçok ayrıntılı. Git mastera git pullveya a yaptığınızda yerel şubeyle ne yapılacağını söyler git push.

4. Varsayılan git pushve git pullgeçerli dalın uzaktan kumandasıyla çalışmaktır. Bu, başlangıç ​​masterından daha iyi bir varsayılan değerdir. Git push'un bunu belirleme şekli burada açıklanmaktadır .

git oldukça zarif ve anlaşılır ancak üzerinde ilerlemek için bir öğrenme eğrisi var.

Git uzaktan kökeni ekle:

Kaynak kodunuzu diğer projelere merkezileştirir.Linux, tam açık kaynak koduna dayalı olarak geliştirilmiştir ve kodunuzu diğer git kullanıcıları için yararlı hale getirir. Referans olarak adlandırıyoruz

Git hub'ının uzak URL'sini kullanarak kodunuzu git deposuna gönderir.