Çıplak ve Çıplak olmayan depo arasındaki -pratik- fark nedir?

Git'teki çıplak ve çıplak / varsayılan olmayan depoları okudum. Aralarındaki farkları ve neden çıplak bir depoya "zorlamam" gerektiğini çok iyi anlayamadım (teorik olarak). İşte anlaşma:

Şu anda, 3 farklı bilgisayarda bir proje üzerinde çalışan tek kişiyim, ancak daha sonra dahil olacak daha fazla insan olacak, bu yüzden Git'i sürüm kontrolü için kullanıyorum. Tüm bilgisayarlarda çıplak repoyu klonluyorum ve bunlardan birinde yaptığım değişiklikleri bitirdiğimde, değişiklikleri çıplak repoya aktarıyorum. Okuduğum kadarıyla, çıplak havuzun bir "çalışma ağacı" yok, bu yüzden çıplak depoyu klonlarsam, bir "çalışma ağacım" olmaz.

Çalışma ağacının taahhüt bilgilerini, dalları vb. Projeden sakladığını tahmin ediyorum. Bu çıplak repoda görünmezdi. Bu yüzden, taahhütleri çalışma ağacı ile repoya "itmek" daha iyi görünüyor.

O zaman neden çıplak depoyu kullanmalıyım ve neden kullanmıyorum? Pratik fark nedir? Sanırım bu, bir proje üzerinde çalışan daha fazla insan için yararlı olmaz.

Bu tür işler için yöntemleriniz nelerdir? Öneriler?

Çıplak ve çıplak olmayan depo arasındaki diğer bir fark, çıplak bir havuzun varsayılan bir uzak kaynak deposuna sahip olmamasıdır :

~/Projects$ git clone --bare test bare
Initialized empty Git repository in /home/derek/Projects/bare/
~/Projects$ cd bare
~/Projects/bare$ git branch -a
* master
~/Projects/bare$ cd ..
~/Projects$ git clone test non-bare
Initialized empty Git repository in /home/derek/Projects/non-bare/.git/
~/Projects$ cd non-bare
~/Projects/non-bare$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

İçin manuel sayfadan git clone --bare:

Ayrıca uzaktan kumandadaki dal başları, ilgili yerel dal başlarına refs / uzaktan kumandalar / orijin / ile eşleştirilmeden doğrudan kopyalanır. Bu seçenek kullanıldığında, ne uzaktan izleme dalları ne de ilgili yapılandırma değişkenleri oluşturulur.

Muhtemelen, çıplak bir havuz oluşturduğunda Git, çıplak havuzun birkaç uzak kullanıcı için başlangıç ​​deposu olarak görev yapacağını varsayar, bu nedenle varsayılan uzak kaynağı oluşturmaz. Bunun anlamı, Git'in bir çalışma alanı olmadan çıplak depoda herhangi bir değişiklik yapmayacağınızı varsaydığı için temel git pullve git pushişlemlerin çalışmadığıdır:

~/Projects/bare$ git push
fatal: No destination configured to push to.
~/Projects/bare$ git pull
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
~/Projects/bare$ 

Çıplak ve çıplak olmayan Git deposu arasındaki ayrım yapay ve yanıltıcıdır çünkü bir çalışma alanı havuzun bir parçası değildir ve bir havuz bir çalışma alanı gerektirmez. Açıkça söylemek gerekirse, bir Git deposu, deponun durumunu tanımlayan nesneleri içerir. Bu nesneler herhangi bir dizinde bulunabilir, ancak genellikle .gitçalışma alanının üst düzey dizinindeki dizinde bulunur. Çalışma alanı, depodaki belirli bir taahhüdü temsil eden bir dizin ağacıdır, ancak herhangi bir dizinde var olabilir veya hiç olmayabilir. Ortam değişkeni, $GIT_DIRbir çalışma alanını köken aldığı depoya bağlar.

Git komutlarında git cloneve git inither ikisinde de --barebaşlangıç ​​çalışma alanı olmadan depolar oluşturan seçenekler bulunur . Git'in iki ayrı, ancak ilgili çalışma alanı ve depo kavramını birleştirmesi ve daha sonra iki fikri ayırmak için kafa karıştırıcı terimi çıplak olarak kullanması talihsiz bir durumdur .

Çıplak bir depo .git klasörünün kendisinden başka bir şey değildir, yani çıplak bir deponun içeriği yerel çalışma havuzunuzdaki .git klasörünün içeriğiyle aynıdır .

• Birden çok katılımcının işlerini zorlamasına izin vermek için uzak sunucuda çıplak depo kullanın.
• Çıplak olmayan - Çalışma ağacına sahip olan, projenize katkıda bulunanların yerel makinelerinde mantıklıdır.

5 yıl çok geç, biliyorum, ama kimse aslında soruyu cevaplamadı:

O zaman neden çıplak depoyu kullanmalıyım ve neden kullanmıyorum? Pratik fark nedir? Sanırım bu, bir proje üzerinde çalışan daha fazla insan için yararlı olmaz.

Bu tür işler için yöntemleriniz nelerdir? Öneriler?

Doğrudan Loeliger / MCullough kitabından alıntı yapmak için (978-1-449-31638-9, s196 / 7):

Çıplak bir depo çok az işe yaramış gibi görünebilir, ancak rolü çok önemlidir: işbirlikçi gelişim için yetkili bir odak noktası olarak hizmet etmek. Diğer geliştiriciler cloneve fetchçıplak depodan ve pushgüncellemelerden ... geliştiricilerin pushdeğiştiği bir havuz oluşturduysanız , çıplak olmalıdır. Aslında, bu, yayınlanan bir deponun çıplak olması gereken daha genel en iyi uygulamanın özel bir durumudur.

Çıplak olmayan bir deponun kullanıma alınmış bir çalışma ağacı vardır. Çalışma ağacı, deponun durumu (dallar, etiketler vb.) Hakkında herhangi bir bilgi depolamaz; bunun yerine, çalışma ağacı yalnızca repodaki gerçek dosyaların bir temsilidir, bu da dosyalar üzerinde çalışmanıza (düzenlemenize vb.) izin verir.

Çıplak bir havuzun

• azaltılmış disk kullanımı
• uzaktan itme ile ilgili daha az sorun (senkronizasyondan çıkmak veya çakışan değişiklikler yapmak için hiçbir çalışma ağacı olmadığından)

Çıplak olmayan depo, (çalışma ağacınıza) yeni taahhütler oluşturarak değişiklikleri yakalamanızı sağlar.

Çıplak depolar yalnızca diğer depolardaki değişiklikleri taşıyarak değiştirilir.

Kesinlikle Git "uzmanı" değilim. Bir süredir TortoiseGit kullandım ve ne zaman yarattığımda "çıplak" bir repo yapmak isteyip istemediğimi sorduğunda ne hakkında konuştuğunu merak ettim. Bu öğreticiyi okuyordum: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init ve bu konuyu ele alıyor, ancak yine de konsepti tam olarak anlayamıyordum. Bu çok yardımcı oldu: http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html . Şimdi, birincisi de mantıklı!

Bu kaynaklara göre, bir dağıtım noktasını kurmak istediğiniz bir sunucuda "çıplak" bir repo kullanılır. Yerel makinenizde kullanım için tasarlanmamıştır. Genellikle yerel makinenizden uzak bir sunucudaki çıplak bir repoya taahhüt verirsiniz ve siz ve / veya diğerleri bu çıplak repodan yerel makinenize çekersiniz. Bu nedenle GitHub, Assembla vb. Uzak depolama / dağıtım deponuz "çıplak" bir repo oluşturduğunuz bir örnektir. Kendi benzer "paylaşım merkezinizi" kurarsanız kendiniz bir tane yaparsınız.

Varsayılan / çıplak olmayan Git deposu iki durum içerir:

1. Bir anlık veri havuzundaki tüm dosyaların (bu Git jargon ne "çalışma ağaç" yoludur)
2. Bir tarih hiç depoda olmuştur tüm dosyalara yapılan tüm değişikliklerin (tüm bu kapsar Git jargon bir özlü parçası olmak görünmüyor)

Anlık muhtemelen proje olarak düşünmek budur: kodunuzu dosyaları, yapı dosyaları, yardımcı betikler ve Git ile başka bir şey sürümü.

Tarih Farklı işlemek kontrol ve deposundaki dosyalar eklendi kesinleştirme o zaman neye benzediğini tam bir anlık ulaşmasını sağlar durumudur. Git'in içinde, muhtemelen doğrudan etkileşimde bulunmadığınız bir grup veri yapısından oluşur. Önemli olarak, geçmiş yalnızca meta verileri depolamakla kalmaz (ör. "U kullanıcısı, Komut C'nin bir parçası olarak T Zamanında Dosya F'ye bu kadar çok satır ekledi"), aynı zamanda verileri de saklar (örn. "Kullanıcı U bu tam satırları Dosya F'ye ekledi " ).

Çıplak bir deponun ana fikri, anlık görüntüye sahip olmanıza gerek olmamasıdır. Git, anlık görüntüyü saklar çünkü kodunuzla etkileşim kurmak isteyen insanlar ve diğer Git olmayan işlemler için uygundur, ancak anlık görüntü zaten geçmişte olan yinelenen durumdur.

Bir çıplak depo anlık olmayan bir Git deposu olduğunu. Sadece tarihi saklar.

Bunu neden istiyorsun? Eh, yalnızca Git'i kullanarak dosyalarınızla etkileşime girecekseniz (yani, dosyalarınızı doğrudan düzenlemeyecek veya bir yürütülebilir dosya oluşturmak için kullanamayacaksınız), anlık görüntüyü tutmadan yerden tasarruf edebilirsiniz. Özellikle, bir yerde bir sunucuda repo'nuzun merkezi bir sürümünü koruyorsanız (yani temel olarak kendi GitHub'ınızı barındırıyorsanız), bu sunucunun muhtemelen çıplak bir repoya sahip olması gerekir (yine de yerel makine olsa da, muhtemelen anlık görüntünüzü düzenlemek isteyeceksiniz).

Çıplak depoların ve başka bir örnek kullanım durumunun daha ayrıntılı bir açıklamasını istiyorsanız, buraya bir blog yazısı yazdım: https://stegosaurusdormant.com/bare-git-repo/

Bu yeni bir cevap değil, ama yukarıdaki cevapların farklı yönlerini anlamama yardımcı oldu (ve bir yorum için çok fazla).

Git Bash kullanarak şunları deneyin:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init
Initialized empty Git repository in C:/Test/.git/

me@pc MINGW64 /c/Test (master)
$ ls -al
total 20
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 .git/

me@pc MINGW64 /c/Test (master)
$ cd .git

me@pc MINGW64 /c/Test/.git (GIT_DIR!)
$ ls -al
total 15
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ../
-rw-r--r-- 1 myid 1049089 130 Apr  1 11:35 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:35 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:35 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 objects/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 refs/

Şununla aynı git --bare:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init --bare
Initialized empty Git repository in C:/Test/

me@pc MINGW64 /c/Test (BARE:master)
$ ls -al
total 23
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:11 ../
-rw-r--r-- 1 myid 1049089 104 Apr  1 11:36 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:36 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:36 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 objects/

$ git help repository-layout

Git deposu iki farklı aromada gelir:

• çalışma ağacının kökündeki bir .git dizini;
• çıplak bir depo olan (yani kendi çalışma ağacı olmayan) .git dizini , genellikle içine iterek ve ondan getirerek başkalarıyla tarih alışverişinde bulunmak için kullanılır.