Bu kelimeler Git'te ne anlama geliyor: Depo, çatal, dallanma, klonlama, izleme?

130

Dürüst olmak gerekirse, buradaki anlambilim konusunda net değilim. Hepsi bir kod + geçmiş biriminin kopyaları / varyantları hakkındadır, ancak geçmişte söyleyebileceğimden emin değilim. Bu mantıksal yapı bir yerde açıklanmış mı?

git branch clone

— Eric Anderson
kaynak

5

Pro Git kitabının ( progit.org/book ) ilk birkaç bölümünü okumanızı tavsiye ederim .

— ewall

61

+1. Git öğreticilerinin çoğu, belirli kelimelerin ne anlama geldiğini veya git'in nasıl çalıştığını açıklamadan belirli görevleri nasıl gerçekleştireceğinizi gösterir. Bu konuyu ele alan bir kaynak istemek meşru bir sorudur.

— Daniel Stutzbach

14

Keşke Daniel'ın yorumunu daha fazla + 1'leyebilseydim. Bazı terimlerin (örn. Arşiv) anlamı açık olsa da, ilişkileri her zaman değildir (dallanmaya karşı çatal) ve gerçek anlamı, merkezi bir VCS'ye alışmış biri tarafından kolayca yanlış yorumlanabilir. Ayrıca, Pro Git'in "şube nedir?" bölümü - temel bir kullanıcı gerçekten lekeler ve ağaçlar hakkında bilgi edinmek ister mi, yoksa sadece niteliksel olarak bir dalın ne olduğunu bilmek mi ister?

— Cascabel

1

@DanielStutzbach, kitapta net olmayan şeyler hakkında yorum yapmak mümkündür. (Bunu söylemek için doğru terminolojiyi bilmiyorum.) Bunu yaptım, kitabın bir deponun ne olduğunu tanımlaması gerektiğini söyledim. Bir şeyi çok iyi anlayan insanlardan kavramsal malzeme almanın oldukça zor olduğuna katılıyorum. Bu kitap (şu anda) bu bağlamda ne olduklarını tanımlamadan veri tabanlarından bahsediyor ve depoların ne olduğu hakkında hiçbir şey söylemiyor.

— user34660

146

Depo, basitçe işinizin geçmişinin saklandığı bir yerdir. Genellikle .git, çalışma kopyanızın bir alt dizininde bulunur - üzerinde çalıştığınız dosyaların en son durumunun bir kopyası.

Bir projeyi çatallamak için (kaynağı belirli bir zamanda birinin deposundan almak ve kendi farklı değişikliklerinizi ona uygulamak), bir kopyasını oluşturmak için uzak depoyu klonlar, ardından yerel deponuzda kendi işinizi yapın ve değişiklikleri taahhüt et.

Bir havuzda, kendi deponuzda etkili bir şekilde çatal olan şubeleriniz vardır. Şubeleriniz deponuzda bir ata kaydına sahip olacak ve değişikliklerinizle bu taahhütten ayrılacaktır. Daha sonra şube değişikliklerinizi birleştirebilirsiniz. Dallar, aynı anda birden çok farklı özellik üzerinde çalışmanıza izin verir.

Ayrıca uzak depolarda ayrı şubeleri de izleyebilirsiniz. Bu, başka bir kişinin dallarındaki değişiklikleri almanıza ve bunları kendi dalınızda birleştirmenize olanak tanır. Bu, siz ve bir arkadaşınızla birlikte yeni bir özellik üzerinde çalışıyorsanız faydalı olabilir.

İnternette çok sayıda harika git kitabı var. Başlamak için ProGit ve Git Magic'in yanı sıra resmi öğreticiler ve topluluk kitabına bir göz atın .

— NFM
kaynak

Elbette F kılavuzlarını ve eğitimlerini okumak çok önemlidir. Ama bu bana her şeyin harika bir özeti gibi görünüyor. Çok takdir!

— brasofilo

Yerel çalışma dizininizi yeni bir şubeye ("git checkout <new_branch>") geçirebileceğinizi unutmayın. Bu durumda, yerel çalışma dizininizin dosyaları, geçiş yaptığınız dalın içeriğine göre DEĞİŞTİRİLİR. Ancak işinizi kaybetmezsiniz: Git, önceki dalda yaptığınız tüm taahhüt edilmiş değişiklikleri ("git commit") Git "veritabanında" (gizli .git klasörü) depolar ve dosyalarınızı geri almanıza izin verir.

— KrisWebDev

3

Sanırım, hangi VCS'yi kullandığınıza bakılmaksızın, çatallamanın ve dallanmanın iki ayrı şey olarak kabul edildiğini tarihsel olarak özel olarak belirtmeyi gerektiriyor. Dallanma, geliştiriciler arasında olumlu ve zımni bir anlaşma olarak kabul edildi. Forking, bir proje üzerinde çalışan geliştiricilerin bazı konularda hemfikir olmadıklarını ve yolları ayırmaya karar verdiklerini ima ettiğinden daha ciddiydi. Başarılı çatallar, her iki tarafın da bir anlaşmaya varmasından sonra tipik olarak tek bir projede birleştirildi. O zamandan beri Git (ve GitHub) bu terimleri bulanıklaştırdı ve her iki terim de temelde aynı fikri, ancak farklı şekillerde temsil ediyor.

— redteam316

Yani bir arşivde proje için dosyalar yok mu? İşinizin geçmişinin saklandığı bir yer söylüyorsunuz . Hepsi bu? Yalnızca dosyaların geçmişi, ancak dosyaların kendileri değil mi?

— user34660

13

Kendi sorumu bir RTFM ile cevaplayacağım.

Ancak, bu güzel kılavuzu okuyun . Yazarın belirttiği gibi:

“Buradan çıkardığım sonuç, Git'i ancak Git'in nasıl çalıştığını anlarsanız gerçekten kullanabileceğinizdir. Kısa vadede hangi zamanlarda hangi komutları çalıştırmanız gerektiğini ezberlemek, ancak takılıp kalmanız veya daha kötüsü bir şeyi kırmanız an meselesidir.

“Git'teki mevcut kaynakların yarısı maalesef tam da bu yaklaşımı benimsiyor: hangi komutların ne zaman çalıştırılacağı konusunda size yol gösteriyorlar ve bu komutları taklit ederseniz iyi yapmanız gerektiğini bekliyorlar. Diğer yarısı tüm kavramların üzerinden geçiyor, ancak gördüğüm kadarıyla Git'i, Git'in nasıl çalıştığını anladığınızı varsayan bir şekilde açıklıyorlar. "

— Eric Anderson
kaynak

Bu giriş sbf5.com/~cduan/technical/git adresine taşınmış gibi görünüyor . Orijinal URL şimdilik hala çalışıyor.

— Eric Anderson

1

Bu bağlam içinde doğrudur. Hemen üretken olmanız veya gerçekten sadece kodu kontrol etmeniz gerekiyorsa, git'in nasıl çalıştığı konusunda derin bir anlayışa sahip olmamanız sorun değil. Öğreticiler gayet iyi. Ben böyle gitmeye başladım. Bununla birlikte, dal oluşturma, çatal, yeniden temel alma ve diğer daha gelişmiş görevler gibi daha gelişmiş olmanız gerekiyorsa, o zaman git'in nasıl çalıştığını bilmeniz gerekir, özellikle de arka planınız merkezi bir kaynak kontrolündeyse.

— Phil

3

Bu GoogleTechTalk , dili öğrenirken perde arkasında gerçekte neler olduğunu öğrenmek için Git'e harika bir giriş niteliğindedir. Git'e çok erken katkıda bulunan bir kişi tarafından verildi ve 2007'de Git'e giriş yapmak için bu konuşmayı yaptı. Bu konuşmayı izlerseniz, sadece depo, çatal, dal vb. Gibi her kelimenin ne olduğunu değil, aynı zamanda bunların her biri yapıldığında, birleştirildiğinde vb. Sahne arkasında neler olduğunu da bileceksiniz.

Adres uzun ama çok bilgilendirici. Ayrıca Git'i diğer Sürüm Kontrol Sistemleriyle karşılaştırır, böylece Git'in neden olduğu gibi yaratıldığını ve diğer kontrol sistemlerine göre karşılaştırmalı avantajlarının neler olduğunu anlayabilirsiniz. Konuşma eski olsa da ayağa kalkıp koşmak çok faydalıdır. Kılavuzlara girmeden önce bunu izlerdim. Sonuç olarak her şeyin çok daha anlamlı olacağına inanıyorum.

— Mat
kaynak