Arasında farklı nedir git initve git init --bare? Blog --baresunucusu için Git sunucusu için bir sürü blog gönderisi gerekli olduğunu buldum.

Gönderen adam sayfasında , deniyor:

--bare

Çıplak bir depo oluşturun. GIT_DIR ortamı ayarlanmamışsa, geçerli çalışma dizinine ayarlanır

Ama aslında ne anlama geliyor? --bareGit sunucusu kurulumu için gerekli mi?

Çıplak Olmayan Git Repo

Bu varyant, gerçekten çalışabilmeniz için çalışma dizinine sahip bir havuz oluşturur ( git clone). Oluşturduktan sonra dizinin geçmişin ve tüm git tesisatının gittiği bir .git klasörü içerdiğini göreceksiniz. .Git klasörünün bulunduğu düzeyde çalışırsınız.

Bare Git Repo

Diğer varyant, çalışma dizini ( git clone --bare) içermeyen bir havuz oluşturur . Çalışabileceğiniz bir dizin elde edemezsiniz. Dizindeki her şey, yukarıdaki durumda .git klasöründe bulunan şeydir.

Neden Birini diğerine Karşı Kullanıyorsunuz

Bir çalışma dizini olmadan git depolarına olan ihtiyaç, şubeleri ona doğru itebileceğiniz ve birisinin üzerinde çalıştığı şeyi yönetmemesi gerçeğidir. Hala çıplak olmayan bir havuza itebilirsiniz, ancak birisinin o çalışma dizininde üzerinde çalıştığı bir dalı taşıyabileceğiniz için reddedilirsiniz.

Dolayısıyla, çalışma klasörü olmayan bir projede, nesneleri yalnızca git onları depolarken görebilirsiniz. Sıkıştırılır ve serileştirilir ve içeriklerinin SHA1 (karma) altında saklanırlar. Bir nesneyi çıplak bir depoya git showalmak için, görmek istediğiniz nesnenin sha1'ini belirtmeniz ve belirtmeniz gerekir . Projenize benzeyen bir yapı görmeyeceksiniz.

Çıplak depolar genellikle herkesin işini yürüttüğü merkezi depolardır. Gerçek çalışmayı manipüle etmeye gerek yoktur. Bu, birden fazla kişi arasındaki çabaları senkronize etmenin bir yoludur. Proje dosyalarınızı doğrudan göremezsiniz.

Projede çalışan tek kişi sizseniz veya "mantıksal olarak merkezi" bir depo istemiyorsanız / buna ihtiyacınız yoksa, herhangi bir çıplak depoya ihtiyacınız olmayabilir. Bir tercih edeceğini git pull gelen bu durumda diğer depoları. Bu git olmayan çıplak depolara itilirken sahip olduğu itirazları önler.

Bu yardımcı olur umarım

Kısa cevap

Çıplak depo, çalışan bir kopyası olmayan bir git deposudur, bu nedenle .git içeriği bu dizin için en üst düzeydedir.

Yerel olarak çalışmak için çıplak olmayan bir depo ve değişikliklerinizi diğer kişilerle paylaşmak için merkezi bir sunucu / hub olarak çıplak bir depo kullanın. Örneğin, github.com'da bir havuz oluşturduğunuzda, çıplak bir depo olarak oluşturulur.

Yani, bilgisayarınızda:

git init
touch README
git add README
git commit -m "initial commit"

sunucuda:

cd /srv/git/project
git init --bare

Sonra istemcide, itin:

git push username@server:/srv/git/project master

Daha sonra uzaktan kumandayı ekleyerek yazmayı kaydedebilirsiniz.

Sunucu tarafındaki depo, dosyaları düzenleyip sonra sunucu makinesinde gerçekleştirerek değil, çekme ve itme yoluyla taahhütleri alacaktır, bu nedenle çıplak bir havuzdur.

ayrıntılar

Çıplak bir depo olmayan bir havuza itebilirsiniz ve git orada bir .git deposu olduğunu öğrenecektir, ancak çoğu "hub" havuzunun çalışan bir kopyaya ihtiyacı olmadığı için, çıplak bir depo kullanmak normaldir. ve bu tür depolarda çalışan bir kopyaya sahip olmanın bir anlamı olmadığı için önerilir.

Ancak, çıplak olmayan bir depoya basarsanız, çalışma kopyasını tutarsız hale getirirsiniz ve git sizi uyarır:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

Bu uyarıyı atlayabilirsiniz. Ancak önerilen kurulum: yerel olarak çalışmak için çıplak olmayan bir depo ve itmek ve almak için bir hub veya merkezi sunucu olarak çıplak bir havuz kullanmaktır.

Çalışmayı doğrudan diğer geliştiricinin çalışma kopyasıyla paylaşmak istiyorsanız, itmek yerine birbirinden depolardan çekebilirsiniz.

Bu soruyu bir süre önce okuduğumda, her şey benim için kafa karıştırıyordu. Git'i kullanmaya başladım ve bu çalışma kopyaları var (o zaman hiçbir şey ifade etmiyordu). Bunu terminoloji hakkında hiçbir fikri olmayan gitmeye başlayan adamın bakış açısından açıklamaya çalışacağım.

Farklılıklara güzel bir örnek şu şekilde tanımlanabilir :

--baresize sadece bir depolama yeri verir (orada gelişemezsiniz). O olmadan --baresize orada geliştirme yeteneği verir (ve bir depolama yeri var).

git initgeçerli dizininizden bir git deposu oluşturur. İçine .git klasörü ekler ve düzeltme geçmişinizi başlatmanızı sağlar.

git init --bareayrıca bir havuz oluşturur, ancak çalışma dizini yoktur. Bu, dosyaları düzenleyemeyeceğiniz, değişikliklerinizi yapamayacağınız, bu depoya yeni dosyalar ekleyemeyeceğiniz anlamına gelir.

Ne zaman yardımcı --bareolabilir? Siz ve diğer birkaç kişi proje üzerinde çalışıyorsunuz ve git kullanıyorsunuz. Projeyi bazı sunucularda ( amazon ec2) barındırdınız. Her birinizin kendi makineniz var ve kodunuzu açıyorsunuz ec2. Hiçbiriniz aslında hiçbir şey geliştirmiyorsunuz ec2(makinelerinizi kullanıyorsunuz) - sadece kodunuzu aktarıyorsunuz. Bu nedenle, ec2tüm kodunuz için sadece bir depolama alanıdır --bareve tüm makineleriniz olmadan oluşturulmalıdır --bare(büyük olasılıkla sadece bir tane ve diğeri her şeyi klonlayacaktır). İş akışı şöyle görünür:

Varsayılan Git deposu, onu çalışma dizininiz olarak kullanacağınızı varsayar. Genellikle, bir sunucudayken, çalışan bir dizininiz olması gerekmez. Sadece depo. Bu durumda, --bareseçeneği kullanmalısınız .

Çıplak olmayan bir depo varsayılan değerdir. Çalıştırdığınızda oluşturulan git initveya baresunucudan klonladığınızda ( seçenek olmadan ) elde ettiğiniz şeydir .

Böyle bir havuzla çalıştığınızda, depodaki tüm dosyaları görebilir ve düzenleyebilirsiniz. Depo ile etkileşim kurduğunuzda (örneğin bir değişiklik yaparak) Git, değişikliklerinizi adlı gizli bir dizinde depolar .git.

Git sunucunuz olduğunda, dosyaların çalışan kopyalarının olmasına gerek yoktur. Tek ihtiyacınız olan depolanan Git verisidir .git. Çıplak bir depo, .gitdosyaları değiştirmek ve işlemek için bir çalışma alanı olmadan tam olarak dizindir.

Bir sunucudan .gitkopyaladığınızda Git, çalışma kopyanızı oluşturmak için dizinde ihtiyaç duyduğu tüm bilgilere sahiptir .

- çıplak ve Çalışma Ağacı depoları arasındaki diğer bir fark, ilk durumda kayıp taahhütlerin depolanmaması, ancak yalnızca bir şube izine ait olan taahhütlerin depolanmasıdır. Öte yandan, Çalışma Ağacı tüm taahhütleri sonsuza dek tutar. Aşağıya bakınız...

İlk havuzu (name: git-bare ) ile oluşturdum git init --bare. Sunucu. Sol tarafta, uzak dalların olmadığı yerde, çünkü bu uzak deponun kendisi.

İlkinden ikinci depoyu (isim: git-working-tree ) oluşturdum git clone. sağ tarafta. Uzak şubelere bağlı yerel şubeleri vardır.

('İlk', 'ikinci', 'üçüncü', 'dördüncü', 'alfa', 'beta' ve 'delta' metinleri taahhüt yorumlarıdır. 'Master' ve 'Yunan' isimleri şube isimleridir.)

Şimdi git-bare (command :)git push --delete origin greek ve yerel olarak git-working-tree (command :) içinde 'greek' adlı dalı sileceğim git branch -D greek. Ağaç şöyle görünür:

Git-çıplak depo şube ve tüm başvurulan comits hem siler. Resimde ağacının bu nedenle azaldığını görüyoruz.

Öte yandan, yaygın olarak kullanılan bir yerel depoya eşdeğer olan git-working-tree deposu, artık yalnızca doğrudan git checkout 7fa897b7komutunuzla hashiniz tarafından referans verilebilecek olan taahhütleri silmez . Bu yüzden ağacının değiştirilmiş yapısı yoktur.

KISACA: Taahhütler asla çalışma ağacı depolarına bırakılmaz , ancak çıplak depolarda silinir .

Pratik terimlerle, silinen bir dalı yalnızca yerel bir depoda varsa kurtarabilirsiniz.

Ancak, uzak deponun silinmesinden sonra çıplak deponun boyutunun disk boyutunda azalmaması çok garip . Yani dosyalar hala bir şekilde orada. Depolamaya artık başvurulmayanı veya neye hiç referans verilemediğini (ikinci durum) silerek dökümü yapmak için şu git gc --prunekomutu kullanın: