Git ile büyük ikili dosyaları yönetme

Kaynak kodumun (web uygulaması) bağımlı olduğu büyük ikili dosyaların nasıl işleneceğine dair görüşler arıyorum. Şu anda birkaç alternatifi tartışıyoruz:

1. İkili dosyaları el ile kopyalayın.
   • Pro: Emin değilim.
   • Aksine: Yeni bir site kurarken / eskisini taşırken hata olasılığını arttırdığından buna şiddetle karşıyım. Almak için başka bir engel oluşturur.
2. Hepsini Git ile yönetin .
   • Pro: Önemli bir dosyayı kopyalamayı 'unutma' olasılığını ortadan kaldırır
   • Kontra: Depoyu şişirir ve kod tabanını ve ödünç alma, klonlar, vb. Yönetme esnekliğini azaltır.
3. Ayrı depolar.
   • Pro: Kaynak kodunu kontrol etmek / kopyalamak her zamanki gibi hızlı ve görüntüler kendi depolarında düzgün bir şekilde arşivleniyor.
   • Contra: Projede tek ve sadece Git deposuna sahip olmanın basitliğini kaldırır . Kesinlikle düşünmediğim başka şeyler tanıtıyor.

Bununla ilgili deneyimleriniz / düşünceleriniz neler?

Ayrıca: Herkes birden fazla Git deposuyla ilgili deneyime sahip ve bunları tek bir projede yönetiyor mu?

Dosyalar, içindeki dosyalar ile PDF üreten bir programın görüntüleridir. Dosyalar çok sık değişmeyecek (yıllar içinde olduğu gibi), ancak bir programla çok ilgili. Program dosyalar olmadan çalışmaz.

Program dosyalar olmadan çalışmazsa, bunları ayrı bir repoya bölmek kötü bir fikirdir. Ayrı bir repoya ayırdığımız büyük test paketlerimiz var, ancak bunlar gerçekten "yardımcı" dosyalar.

Ancak, dosyaları ayrı bir repo ile yönetebilir ve daha sonra git-submodulebunları aklı başında bir şekilde projenize çekmek için kullanabilirsiniz . Yani, hala tüm kaynağınızın tam geçmişine sahip olacaksınız, ancak anladığım kadarıyla, resimlerinizin alt modülünde yalnızca bir tane ilgili revizyona sahip olacaksınız. git-submoduleTesis resimlerin doğru sürümüne doğrultusunda kodun doğru sürümüyle tutmaya yardımcı olmalıdır.

İşte Git Book'un alt modüllerine iyi bir giriş .

Git-annex'i son zamanlarda harika bulduğumu keşfettim . Büyük dosyaları verimli bir şekilde yönetmek için tasarlanmıştır. Fotoğraf / müzik (vb.) Koleksiyonlarım için kullanıyorum. Git-ekinin gelişimi çok aktiftir. Dosyaların içeriği Git deposundan kaldırılabilir, yalnızca ağaç hiyerarşisi Git tarafından (semboller aracılığıyla) izlenir. Bununla birlikte, dosyanın içeriğini elde etmek için, çekme / itme işleminden sonra ikinci bir adım gereklidir, örneğin:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Kullanılabilir birçok komut var ve web sitesinde harika bir dokümantasyon var. Debian'da bir paket mevcuttur .

Nisan 2015'ten bu yana başka bir çözüm de Git Büyük Dosya Depolama (LFS) (GitHub tarafından).

Git-lfs kullanır (bkz. Git-lfs.github.com ) ve bunu destekleyen bir sunucu ile test edilmiştir: lfs-test-server :
Meta verileri yalnızca git repo'sunda ve başka bir yerde büyük dosyada saklayabilirsiniz.

Büyük ikili dosyaları Git deposunda akıllıca depolamak için Git uzantısı olan git bup'a bir göz atın .

Bunu bir alt modül olarak kullanmak istersiniz, ancak havuzun işlenmesi zorlaştığından endişelenmenize gerek kalmaz. Örnek kullanım durumlarından biri, Git'te VM görüntülerini depolamaktır.

Aslında daha iyi sıkıştırma oranları görmedim, ancak depolarımın içinde gerçekten büyük ikili dosyalar yok.

Kilometreniz değişebilir.

Git-fat da kullanabilirsiniz . Ben sadece stok Python ve bağlıdır rsync. Ayrıca aşağıdaki Açıklayıcı komutlarla olağan Git iş akışını destekler:

git fat init
git fat push
git fat pull

Ayrıca, deponuza bir .gitfat dosyasını kontrol etmeniz git fatve yönetmek istediğiniz dosya uzantılarını belirtmek için .gitattributes'ınızı değiştirmeniz gerekir .

Normal git addolanı kullanarak bir ikili dosya git fateklersiniz.

Son olarak, ikili dosyalarınızın depolandığı konumun depolar ve kullanıcılar arasında paylaşılabilmesi ve her şeyi desteklemesi avantajına sahiptir rsync.

GÜNCELLEME: Git-SVN köprüsü kullanıyorsanız git-fat kullanmayın. Bu, ikili dosyaları Subversion deponuzdan kaldıracaktır. Ancak, saf bir Git deposu kullanıyorsanız, güzel bir şekilde çalışır.

Alt modülleri (Pat Notz olarak) ya da iki ayrı depo kullanardım. İkili dosyalarınızı çok sık değiştirirseniz, geçmişi temizleyen büyük deponun etkisini en aza indirmeye çalışırım:

Birkaç ay önce çok benzer bir sorun yaşadım: ~ 21 GB MP3 dosyaları, sınıflandırılmamış (kötü isimler, kötü id3'ler, bu MP3 dosyasını beğenip beğenmediğimi bilmiyorum ...) ve üç bilgisayarda çoğaltılmış.

Ana Git deposuyla harici bir sabit disk sürücüsü kullandım ve her bilgisayara klonladım. Sonra, onları alışılmış şekilde sınıflandırmaya başladım (itme, çekme, birleştirme ... birçok kez silme ve yeniden adlandırma).

Sonunda .git dizininde sadece ~ 6 GB MP3 dosyası ve ~ 83 GB vardı. Kullandığım git-write-treeve git-commit-treeataları taahhüt olmadan yeni işlemek oluşturmak ve işlemek bunlara yeni bir şube işaret başladı. Bu dal için "git günlüğü" yalnızca bir taahhüt gösterdi.

Sonra, eski dalı sildim, sadece yeni dalı tuttum, ref-log'ları sildim ve "git prune" komutunu çalıştırdım: bundan sonra .git klasörlerim sadece ~ 6 GB ağırlığında ...

Büyük depoyu zaman zaman aynı şekilde "temizleyebilirsiniz": "Git klon" larınız daha hızlı olacaktır.

Önermek istediğim çözüm artık yetim şubelerine ve etiket mekanizmasının biraz kötüye kullanılmasına dayanıyor. Bundan böyle * Yetim Etiketleri İkili Depolama (OTABS)

TL; DR 12-01-2017 Eğer github'ın LFS'sini ya da başka bir 3. tarafı kullanabiliyorsanız, mutlaka yapmalısınız. Yapamıyorsanız, okumaya devam edin. Dikkat edin, bu çözüm bir hack'tir ve bu şekilde ele alınmalıdır.

OTABS'nin istenen özellikleri

• Bir olan saf git ve git sadece çözüm değil - ya da (github en LFS gibi) 3. parti altyapısı (git-ekinde gibi) herhangi bir 3. parti yazılım olmadan işi alır.
• ikili dosyaları verimli bir şekilde saklar , yani deponuzun geçmişini şişirmez.
• git pullve git fetchdahil git fetch --allhala bant genişliği verimli yani tüm büyük ikili varsayılan olarak uzaktan çekilir değil.
• Windows üzerinde çalışır .
• her şeyi tek bir git deposunda saklar .
• eski ikili dosyaların silinmesine izin verir (bup'ın aksine).

OTABS'nin istenmeyen özellikleri

• git clonepotansiyel olarak verimsiz hale getirir (ancak kullanımınıza bağlı olarak zorunlu değildir). Bu çözümü dağıtırsanız, iş arkadaşlarınıza git clone -b master --single-branch <url>bunun yerine kullanmaları için tavsiyede bulunmanız gerekebilir git clone. Bunun nedeni, git klonunun varsayılan olarak , normalde bant genişliğinizi boşa harcamak istemediğiniz şeyler de dahil olmak üzere, tüm depoları kelimenin tam anlamıyla klonlamasıdır . Alındığı SO 4811434 .
• git fetch <remote> --tagsbant genişliğini verimsiz kılar , ancak depolama verimini zorunlu kılmaz. Meslektaşlarınıza her zaman kullanmamalarını tavsiye edebilirsiniz.
• git gcdeponuzu artık istemediğiniz dosyalardan temizlemek için düzenli olarak bir numara kullanmanız gerekir .
• bup veya git-bigfiles kadar verimli değildir . Ama sırasıyla yapmaya çalıştığınız şey için daha uygun ve daha hazır. Büyük olasılıkla yüz binlerce küçük dosya veya gigabaytlık aralıktaki dosyalarla sorun yaşayabilirsiniz, ancak geçici çözümler için okumaya devam edin.

İkili Dosyaları Ekleme

Başlamadan önce tüm değişikliklerinizi yaptığınızdan emin olun, çalışma ağacınız güncel ve dizininizde herhangi bir taahhüt edilmemiş değişiklik bulunmuyor. Herhangi bir felaket olması durumunda tüm yerel şubelerinizi uzaktan kumandaya (github vb.) İtmek iyi bir fikir olabilir.

1. Yeni bir yetim dalı oluşturun. git checkout --orphan binaryStuffhile yapacak. Bu, herhangi bir diğer şubeyle tamamen bağlantısı kesilen bir dal üretir ve bu dalda yapacağınız ilk taahhüdün hiçbir üst öğesi olmayacak ve bu da kök taahhüdü haline gelecektir.
2. Kullanarak endeksinizi temizleyin git rm --cached * .gitignore.
3. Derin bir nefes alın ve kullanarak tüm çalışma ağacını silin rm -fr * .gitignore. Joker karakterle eşleşmediğinden iç .gitdizine dokunulmaz *.
4. VeryBigBinary.exe veya VeryHeavyDirectory / dizininize kopyalayın.
5. Ekle && taahhüt et.
6. Şimdi zorlaşıyor - uzaktan kumandayı bir dal olarak iterseniz, tüm geliştiricileriniz bir sonraki git fetchbağlantılarını tıkamaya çağırdıklarında indirecekler . Şube yerine etiketi iterek bunu önleyebilirsiniz. Bu, yazma alışkanlıkları varsa git fetch <remote> --tags, ancak bir geçici çözüm için okumaya devam ederse, iş arkadaşınızın bant genişliğini ve dosya sistemi depolamasını etkileyebilir . Devam et vegit tag 1.0.0bin
7. Yetim etiketinizi aktarın git push <remote> 1.0.0bin.
8. İkili dalınızı asla kazara itmemeniz için silebilirsiniz git branch -D binaryStuff. Taahhüdünüz çöp toplama için işaretlenmeyecektir, çünkü üzerine işaret eden bir yetim etiketi 1.0.0binonu canlı tutmak için yeterlidir.

İkili Dosyayı Kontrol Etme

1. VeryBigBinary.exe dosyasını geçerli çalışma ağacına nasıl teslim alabilirim? Mevcut çalışma dalınız örneğin master ise, basitçe yapabilirsiniz git checkout 1.0.0bin -- VeryBigBinary.exe.
2. Artık yetim etiketi 1.0.0binindirilmediyse başarısız olur , bu durumda git fetch <remote> 1.0.0binönceden yapmanız gerekir .
3. Ekibinizdeki hiç kimsenin projenin ana tarihini ikili ile kazara kirletmeyeceği şekilde VeryBigBinary.exemaster'ınıza ekleyebilirsiniz .gitignore.

İkili Dosyayı Tamamen Silme

VeryBigBinary.exe dosyasını yerel deponuzdan, uzak deponuzdan ve iş arkadaşınızın havuzlarından tamamen temizlemeye karar verirseniz şunları yapabilirsiniz:

1. Uzaktan kumandadaki yetim etiketini silme git push <remote> :refs/tags/1.0.0bin
2. Yetim etiketini yerel olarak sil (referans gösterilmeyen diğer tüm etiketleri siler) git tag -l | xargs git tag -d && git fetch --tags. Alındığı SO 1841341 ufak bir değişiklikle.
3. Şimdi başvurulmamış taahhüdünüzü yerel olarak silmek için bir git gc hilesi kullanın. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". Ayrıca diğer tüm referanslandırılmamış taahhütleri de silecektir. Alındığı SO 1904860
4. Mümkünse, uzaktan kumandadaki git gc numarasını tekrarlayın. Deponuzu kendiniz barındırıyorsanız ve github gibi bazı git sağlayıcılarıyla veya bazı şirket ortamlarında mümkün olmayabilir. Eğer uzaktan kumandaya ssh erişimi vermeyen bir sağlayıcı ile ev sahipliği yapıyorsanız, bırakın. Sağlayıcınızın altyapısının, referans alınmayan taahhüdünüzü kendi tatlı zamanlarında temizlemesi mümkündür. Kurumsal bir ortamdaysanız, BT'nize haftada bir kez uzaktan kumandanızı toplayan bir cron iş çöpü çalıştırmasını tavsiye edebilirsiniz. İş arkadaşlarınıza her zaman git clone -b master --single-branch <url>bunun yerine tavsiyede bulunduğunuz sürece, bant genişliği ve depolama açısından ekibiniz üzerinde herhangi bir etkisinin olup olmayacağı git clone.
5. Eski yetim etiketlerinden kurtulmak isteyen tüm iş arkadaşlarınızın yalnızca 2-3. Adımları uygulamaları gerekir.
6. Daha sonra, yeni bir yetim etiketi oluşturmak için İkili Dosyaları Ekleme'nin 1-8 arasındaki adımları tekrarlayabilirsiniz 2.0.0bin. İş arkadaşlarınızın yazmasından endişe git fetch <remote> --tagsediyorsanız, aslında tekrar adlandırabilirsiniz 1.0.0bin. Bu, bir dahaki sefere tüm etiketleri getirdiklerinde eski etiketin 1.0.0binreferanssız hale getirilmesini ve sonraki çöp toplama işlemi için işaretlenmesini sağlayacaktır (3. adım kullanılarak). Uzaktan kumandadaki bir etiketin üzerine yazmaya çalıştığınızda şu şekilde kullanmanız gerekir -f:git push -f <remote> <tagname>

Sonsöz

• OTABS, master'ınıza veya başka bir kaynak koduna / geliştirme dalına dokunmaz. Taahhüt karmaları, tüm tarih ve bu dalların küçük boyutu etkilenmez. Kaynak kodu geçmişinizi zaten ikili dosyalarla şişirdiyseniz, ayrı bir iş parçası olarak temizlemeniz gerekir. Bu komut dosyası yararlı olabilir.

• Git-bash ile Windows üzerinde çalıştığı onaylandı.

• İkili dosyaların depolanmasını daha verimli hale getirmek için bir dizi standart test uygulamak iyi bir fikirdir . Sık sık çalıştırılması git gc(ek argüman olmadan) git, ikili deltaları kullanarak dosyalarınızın altında yatan depolamayı optimize eder. Ancak, dosyalarınızın taahhütten taahhütlüğe benzememesi olasıysa, ikili deltaları tamamen kapatabilirsiniz. Ayrıca, .zip, .jpg veya .crypt gibi sıkıştırılmış veya şifrelenmiş dosyaları sıkıştırmanın bir anlamı olmadığı için git, temeldeki depolamanın sıkıştırmasını kapatmanıza izin verir. Ne yazık ki, kaynak kodunuzu da etkileyen ya hep ya hiç.

• Daha hızlı kullanıma izin vermek için OTABS bölümlerini kodlamak isteyebilirsiniz. Özellikle, İkili Dosyaların Tamamen Bir updateGit Kancasına Silinmesi'nden 2-3. Adımların yazılması, git getirmeye zorlayıcı ama belki de tehlikeli bir anlam verebilir ("güncel olmayan her şeyi getir ve sil").

• Uzaktan kumandadaki tüm ikili değişikliklerin tam geçmişini merkezi depo şişirme maliyetiyle tutmak için İkili Dosyaları Tamamen Silme adım 4'ü atlamak isteyebilirsiniz . Yerel depolar zamanla zayıf kalacak.

• Java dünyasında, bu çözümü maven --offlinetamamen sürüm kontrolünüzde saklanan tekrarlanabilir bir çevrimdışı yapı oluşturmak için birleştirmek mümkündür (maven ile sınıftan daha kolaydır). Golang dünyasında, GOPATH'inizi yönetmek için bu çözüm üzerine inşa etmek mümkündür go get. Python dünyasında, sıfırdan her yapı için PyPi sunucularına güvenmeden bağımsız bir geliştirme ortamı üretmek için bunu virtualenv ile birleştirmek mümkündür.

• Lütfen ikili dosyaları inşa eserler gibi çok sık değiştirirseniz, çözüm yetim etiketleri saklar eserler 5 en son sürümlerini komut için iyi bir fikir olabilir monday_bin, tuesday_bin, ..., friday_binher yayın için ve ayrıca bir yetim etiketi Eski ikili dosyaları günlük olarak 1.7.8bin 2.0.0bindöndürebilir weekday_binve silebilirsiniz. Bu şekilde iki dünyanın en iyisini elde edersiniz: kaynak kodunuzun tüm geçmişini ancak ikili bağımlılıklarınızın yalnızca ilgili geçmişini tutarsınız . Tüm geçmişiyle birlikte tüm kaynak kodunu almadan belirli bir etiket için ikili dosyaları almak da çok kolaydır : git init && git remote add <name> <url> && git fetch <name> <tag>sizin için yapmalıdır.

Bence, bu büyük dosyaları sık sık değiştirmeniz gerekiyorsa veya çok fazla git cloneveya yapmak git checkoutistiyorsanız, başka bir Git deposunu (veya bu dosyalara erişmenin başka bir yolunu) ciddi şekilde düşünmelisiniz.

Ancak bizim yaptığımız gibi çalışırsanız ve ikili dosyalarınız sık sık değiştirilmezse, ilk klon / ödeme uzun olacaktır, ancak bundan sonra istediğiniz kadar hızlı olmalıdır (kullanıcılarınız ilk klonlanan depoyu kullanmaya devam ettiklerini düşünerek) vardı).

SVN, ikili deltaları Git'ten daha verimli işliyor gibi görünüyor.

Belgeleme için bir sürüm sistemine karar vermeliydim (JPEG dosyaları, PDF dosyaları ve .odt dosyaları). Sadece bir JPEG dosyası eklemeyi ve dört kez 90 derece döndürmeyi test ettim (ikili deltaların etkinliğini kontrol etmek için). Git'in deposu% 400 büyüdü. SVN'nin deposu sadece% 11 büyüdü.

Yani SVN ikili dosyalar ile çok daha verimli görünüyor.

Bu yüzden seçimim kaynak kodu için Git ve belge gibi ikili dosyalar için SVN.

git clone --filter Git 2.19 + sığ klonlardan

Bu yeni seçenek, Git ve GitHub cihazlarını geliştirip yeterince kullanıcı dostu hale getirirse (örneğin muhtemelen alt modüller için hala ulaşamadıkları takdirde) ikili dosya sorununun nihai çözümü haline gelebilir .

Aslında sadece sunucu için istediğiniz dosyaları ve dizinleri getirmeye izin verir ve bir uzak protokol uzantısı ile birlikte tanıtıldı.

Bununla, önce sığ bir klon yapabiliriz ve daha sonra her bir yapı türü için yapı sistemiyle hangi blokları getireceğini otomatikleştirebiliriz.

--filter=blob:limit<size>Maksimum blob boyutunun getirilmesini sınırlamaya izin veren bir tane bile var .

Özelliğin nasıl göründüğüne dair çok az ayrıntılı bir örnek sağladım: Yalnızca Git deposunun bir alt dizinini nasıl klonlayabilirim?

Kaynak kodumun (web uygulaması) bağımlı olduğu büyük ikili dosyaların nasıl işleneceğine dair görüşler arıyorum. Bununla ilgili deneyimleriniz / düşünceleriniz neler?

Şahsen web uygulamaları ikili verilerim 3 GB işaretinin üzerinde çentiklendikten sonra Git ile bazı bulut sunucularım ile senkronizasyon hatalarıyla karşılaştım . O zamanlar BFT Repo Cleaner'ı düşündüm , ancak bir hack gibi hissettim. O zamandan beri dosyaları Git purview'in dışında tutmaya başladım, bunun yerine dosyaları yönetmek, versiyonlamak ve yedeklemek için Amazon S3 gibi amaca yönelik araçlar kullandım .

Birden fazla Git deposu kullanma ve bunları tek bir projede yönetme deneyimi olan var mı?

Evet. Hugo temaları öncelikle bu şekilde yönetiliyor. Biraz tombul, ama işi hallediyor.

Benim önerim iş için doğru aracı seçmektir . Bir şirket içinse ve GitHub'daki kod hattınızı yönetiyorsanız parayı ödeyin ve Git-LFS kullanın. Aksi takdirde, blockchain kullanarak merkezi olmayan, şifreli dosya depolama gibi daha yaratıcı seçenekleri keşfedebilirsiniz .

Dikkate alınması gereken ek seçenekler arasında Minio ve s3cmd bulunur .

Camlistore'a bir göz atın . Gerçekten Git tabanlı değil, ama yapmanız gerekenler için daha uygun buluyorum.