Git ve Github'u sürüm kontrolü olarak kullanan dağıtılmış bir ekip için, görüntüler de git deposunda mı saklanmalıdır?
Çoğunlukla, görüntüler değiştirilmez. Bunları içeren klasör yalnızca resim eklendikçe büyür. Bir endişe, görüntü klasörünün, büyük görüntülerin birleşimi veya sadece birçoğu ile zaman içinde büyük bir boyuta büyüyebilmesidir.
Bu en iyi uygulama olarak mı görülüyor? Dağıtılmış bir ekibin kolayca erişebileceği projelerde gerekli ikili dosyaları paylaşmak için başka alternatifler nelerdir?
Resimleriniz orijinal mi çalışıyor veya başka bir yerden mi kurtarılacak (garanti edilebilir?)? Kaynaktan oluşturulmuş bir yazılım birimi göndermeleri gerekiyor mu? Eğer orijinal iseler, yedeklenmeleri gerekir. Onları revizyon kontrolünüze koyun, eğer hiç değişmezlerse, alan cezası bir yedekle aynıdır ve ihtiyacınız olan yerdedir.
Yanlışlıkla veya kasıtlı olarak yazılımın görünümünü değiştirmek için düzenlenebilirler mi? Evet - o zaman bir şekilde revizyon kontrol edilmeli ZORUNLU, neden mükemmel bir çözümünüz olduğunda başka bir yol kullanıyorsunuz? Neden karanlık çağlardan "kopyala ve yeniden adlandır" versiyon kontrolü uygulanmalı?
Grafik tasarımcının MacBook sabit diski öldüğünde, tüm projenin orijinal sanat eserinin "puf" gittiğini gördüm, çünkü sonsuz bilgeliğe sahip biri "ikili dosyaların devir kontrolüne ait olmadığına" ve grafik tasarımcılarına (en azından bu ) yedekleme konusunda iyi olma eğilimindedir.
Aynı şey, yukarıdaki ölçütlere uyan tüm ikili dosyalar için de geçerlidir.
Olmamasının tek nedeni disk alanıdır. 100 $/terabayttan korkuyorum, bu mazeret biraz zayıflıyor.
İkili dosyaları depolamak kötü bir uygulama olarak kabul edilir, evet, ama görüntüler hakkında asla çok fazla endişelenmedim.
En kötü durum, tonunuz varsa, başka bir yerde saklayın veya harici destek veya ikili destek için bir uzantı kullanın. Ve görüntüler bu kadar sık değiştirilmezse, sorun nerede? Büyük bir şişman delta almayacaksın. Ve zaman içinde kaldırılırlarsa, yalnızca sunucunuz geçmişi depolamaktan biraz acı çeker, ancak istemciler bir şey görmez.
Bence bunun için endişelenmemelisiniz - GB'ları saklamamanız gerekir.
Yapabileceğiniz , sadece "kaynak" görüntüleri saklamaktır: SVG'ler, LaTeX makroları, vb ... sistemi. Mümkünse, bu muhtemelen daha da iyidir. Değilse, rahatsız etmeyin.
(Tüm söylenenler, Git metin dosyaları için parlar, ancak resimler için en iyi VCS değildir. Mümkünse bize daha fazla bağlam ve metrik verin)
Ek bilgi için şu Soru ve Cevaplara bakmak isteyebilirsiniz:
Bu soru oldukça eski ama Git ile uğraşırken ortaya çıkan yaygın bir soru ve son yanıttan bu yana büyük dosyaları bir Git deposunda depolamak için modern çözümler konusunda bazı ilerlemeler var.
Git'te büyük dosyaları depolamak için aşağıdaki projeler vardır:
TLDR: Yapabiliyorsanız, görüntüleri veya diğer ikili dosyaları git'te depolamak için git-lfs kullanın.
Tüm "ikili dosyaları kaynak denetiminde saklamayın" belirli bir nedenle belirtilir: Derleyen kaynak kodunuz varsa, gerçek derlemeyi değil, yalnızca kaynak kodunu saklayın. Resimler ve görsel varlıkların bir "kaynağı" yoktur, bu nedenle sürüm kontrolünde gerekir izlenirler.
Git için önerilen yolun temel olarak ana modülle ilişkili ayrı bir havuz olan bir alt modül (Git 1.5.3'te tanıtıldı) kullanmak olduğuna inanıyorum. Resimlerinizi (ve diğer ikili varlıkları) alt modülde saklarsınız. Bu, gerekli olana bağlı olarak ana depodan veya soldan kontrol edilebilir.
"Git'in alt modül desteği, bir deponun alt dizin olarak harici bir projenin çıkışını içermesine izin verir. Alt modüller kendi kimliklerini korur; alt modül desteği sadece alt modül depo konumunu ve işlem kimliğini depolar, böylece içeren projeyi klonlayan diğer geliştiriciler (" superproject ") tüm alt modülleri aynı revizyonda kolayca klonlayabilir. Süper projenin kısmi kontrolleri mümkündür: Git'e alt modüllerin hiçbirini, bir kısmını veya tamamını klonlamasını söyleyebilirsiniz."
Ayrıca, resimler sık sık değişmezse boyut önemli bir sorun olmamalıdır. Boyutu küçültmek/küçültmek için aşağıdaki gibi komutları da çalıştırabilirsiniz:
git gc git gc-aggressive git Prune
Evet.
Diyelim ki yazılım sürümü 1.0. Sürüm 2.0 için, gölgeli tüm resimleri yeniden yapmaya karar verdiniz. Böylece bunu yaparsınız ve 2.0 sürümü. Sonra 1.0 kullanan ve 2.0'a yükseltemeyen bazı müşteriler programı başka bir dilde istediklerine karar verirler. Bunu yapmak için size 1G dolar veriyorlar, bu yüzden emin ol. Ama farklı bir kültürde, bazı resimleriniz mantıklı değil, bu yüzden onları değiştirmeniz gerekiyor ...
Resimlerinizi kaynak kontrolünde tutarsanız, bu kolaydır, 1.0'a dayanarak görüntülerde değişiklikler yapabilirsiniz (diğer şeylerin yanı sıra), derleyin, bırakın. Bunları kaynak kontrolünde almadıysanız, eski görüntüleri bulmak, değiştirmek ve sonra oluşturmak zorunda kalacağınız için çok daha zor zamanınız olurdu.
Projenin bir parçasıysa, VCS'de olması gerekir. Bunu en iyi şekilde nasıl elde edeceğiniz, VCS'ye veya bir Projeyi nasıl organize ettiğinize bağlı olabilir. Belki de tasarımcılar için bir repo ve sadece kodlayıcının repo sonuçları, ya da sadece 'Görüntü kaynakları' (bir zamanlar sadece bir .svg dosyası ve make/inscape cli ile oluşturulan görüntüleri bir proje vardı).
Ancak, bir VCS bunu kaldıramazsa veya kullanılamaz hale gelirse, işiniz için doğru araç olmadığını söyleyebilirim.
Şimdiye kadar, git web projeleri için grafik (mockups, kavramlar ve sayfa grafik) 'normal' miktarları koymak ile hiç problem yaşamadım.
Görüntülerinizi SCM'de saklamalısınız: evet. Hiç şüphesiz.
Resimlerinizi git'te saklamalısınız: bu daha zor olur.
git metin dosyaları ile çok iyidir, ancak doğası gereği ikili dosyalar için çok sıcak değildir. Klonladığınızda veya Push ettiğinizde aktarılan verilerin boyutu ile ilgili sorunlarınız olacak, .git dizinleriniz büyüyecek ve birleştirme ile doğru bir karışıklık yaşayabilirsiniz (yani 2 görüntüyü nasıl birleştirirsiniz!)
Bir cevap, alt modüllerin kullanılmasıdır, çünkü bu, projeniz ve görüntüler arasındaki bağın daha zayıf olacağı anlamına gelir - böylece görüntüleri kaynağınızın bir parçasıymış gibi yönetmeniz gerekmez, ancak yine de kontrol altında tutarsınız ve onları alt kollara ayırmaktan endişe ediyor - alt projenin, alışılmış geliştirme sürecinde aynı karmaşadan geçmeyen sadece 'düz' bir veri havuzu olduğu varsayılarak.
Diğer cevap, onları farklı bir projeye koymak, asla dallamamak ve bu projeyi taahhüt eden herkesin hemen yukarı doğru itmesini sağlamak - 2 kişinin dosyanın aynı sürümünü değiştirmesine izin vermeyin - bunu en zor bulacaksınız git gibi bir yönü dağıtılmamış bir iş akışı için tasarlanmamıştır. Bu kuralı korumak için eski moda iletişim yöntemlerini kullanmanız gerekecektir.
Üçüncü cevap, tamamen görüntülerle çalışmaya daha iyi yönelik farklı bir SCM'ye yerleştirmektir.
@ Haylem'in cevabına ek olarak, boyutun bunda büyük bir faktör olduğunu unutmayın. VCS'ye bağlı olarak tonlarca görüntü ile iyi çalışmayabilir. Klonlar veya büyük itmeler bütün gece çekilmeye başladığında, tüm görüntüler zaten deponuzda olduğu için gerçekten çok geç.
Büyük resimler ve gelecekteki büyüme için plan yapın. Bu projeye iki yıl girmek ve "ah saçmalık, belki de repo biraz çok büyük."
Teknik ve ekonomik olarak depolamanın mümkün olduğuna kesinlikle katılıyorum. Question "Bu resimler nakliye ürününün parçası mı yoksa nakliye ürünü içeriğinin bir parçası mı?" İçeriği GIT'te (veya başka bir VCS'de) depolayamayacağınız için değil, ayrı bir VCS için ayrı bir sorun olduğu anlamına gelmez.