Git deponuzda büyük dosyalarla çalışma

Azure DevOps Hizmetleri | Azure DevOps Server | Azure DevOps Server 2022

Kaynak dosyalar için Git, bağımlılıklar için Azure Artifacts ve sık değişen büyük ikili dosyalar için Git LFS kullanın. Deponuz zaten büyük dosyalar içeriyorsa, bu makale Git'te neleri tutabileceğinize, neleri taşıyabileceğinize ve geçmişe ait ikili dosyaların ne zaman kaldırılacağına karar vermenize yardımcı olur.

Her dosyanın nerede depolandığına karar verme

Zaten bir depoda bulunan dosyalarla ne yapacağınıza karar verirseniz buradan başlayın:

  • Kaynak dosyaları, betikleri ve metin dosyalarını Git'te tutun.
  • Bağımlılıkları ve yeniden kullanılabilir paketleri Azure Artifacts paket yönetimine taşıyın.
  • Git LFS'i sık değişen ve iyi fark etmeyen büyük ikili dosyalar için kullanın.
  • Depoya zaten eklenmiş ve artık orada bulunmaması gereken büyük ikili dosyaları depo geçmişinden kaldırın. Bkz. Depodan büyük dosyaları kaldırma.

Deponuz zaten büyükse bir depolama yaklaşımı seçmeden önce depoyu ve gönderme sınırlarını gözden geçirin. Bkz. Büyük depoları etkileyen dosya, gönderme ve yol sınırları için Git sınırları.

Git, paket yönetimi ve Git LFS için doğru depolama seçeneğini belirleyin

En uygunu seçmek için bu tabloyu kullanın.

Dosya türü veya senaryo Use
Kaynak kodu, betikler ve metin dosyaları Git
Bağımlılıklar ve yeniden kullanılabilir paketler Azure Artifacts paket yönetimi
Sık değişen büyük ikili dosyalar Git LFS
Azure DevOps Server Git LFS ve Kerberos Bu makaledeki Kerberos kılavuzuna ve sonundaki bağlantılı makaleye bakın

Git, metin tabanlı kaynak dosyalar ve küçük, okunabilir artışlarla değişen diğer içerikler için en iyi şekilde çalışır.

Büyük ikili dosyalar normal Git depolama için uygun değildir çünkü:

  • Git kaynak kodu, betikler ve metin dosyaları için sürüm farklılıklarını verimli bir şekilde depolar.
  • Sürümler arasında tamamen değişen büyük dosyalar verimli biçimde sıkıştırılamaz veya farkları verimli biçimde çıkarılamaz.
  • Büyük ikili dosyalar clone, fetch, branch ve checkout sürelerini artırır.

Deponuza ikili dosyalar gibi büyük, fark edilemeyen dosyalar eklerseniz, deponuzda her değişiklik yaptığınız her seferde bu dosyaların tam bir kopyasını saklarsınız. Deponuzda bu dosyaların birçok sürümü varsa kodunuzu kullanıma alma, dallama, getirme ve kopyalama süresini önemli ölçüde artırır.

Hangi dosyalar Git'e aittir?

Dosya türüne ve ne sıklıkta değiştiğine uyan en basit seçeneği kullanın.

Kaynak kodu bağımlılıklarda değil Git'te tutma

Ekibinizin doğrudan düzenlediği dosyalar için Git'i kullanın. Bağımlılıkları depodan uzak tutun ve paket yönetimi aracılığıyla teslim edin.

  • Kaynak dosyaları Git'e yerleştirin.
  • DLL'leri, kitaplık dosyalarını ve depo dışındaki diğer bağımlılıkları depolayın.
  • Bağımlılıkları sürüm ve dağıtım için paket yönetimini kullanın.

Paket yönetimi bağımlılıklarınızı paketler ve paketi dağıttığınızda dosyaları sisteminize yükler. Paketler, ortamlar aynı yüklü paketlere sahip olduğu sürece bir ortamda test edilen kodun başka bir ortamda aynı şekilde çalıştığından emin olmak için sürümlenir.

Derleme çıktılarını commit etmeyin.

Git'i derleme çıkışı veya test yapıtları için değil, kaynak için kullanın.

  • İkili dosyaları, günlükleri, izleme çıktılarını veya tanılama verilerini depoya eklemeyin.
  • İş öğesi izleme veya ekip dosyası paylaşımı aracılığıyla günlükleri ve izleme bilgilerini paylaşın.

Git'te küçük ikili dosyaları depolama

Git'i yalnızca seyrek değişen küçük ikili dosyalar için kullanın.

  • Web görüntüleri, simgeler ve diğer küçük resim varlıkları iyi örneklerdir.
  • Bu dosyaların Git'te tutulması, ekip için tutarlı bir iş akışını korur.

Önemli

Küçük ikili kodlar bile sık güncellenirse sorunlara neden olabilir. Örneğin, 100 KB ikili dosyada yapılan 100 değişiklik, 1 MB ikili dosyada 10 değişiklik kadar depolama alanı kullanır. Güncelleştirmelerin sıklığı nedeniyle, küçük ikili dosya büyük ikili dosyadan daha sık dallanma performansını yavaşlatır.

Büyük ve sık güncelleştirilen ikili varlıklardan kaçının

Bu dosyalar genellikle sürümler arasında değiştiği ve genellikle zaten sıkıştırılmış olduğundan Git büyük ikili dosyaları verimli bir şekilde depolayamaz.

  • Git, her sürümün tam içeriğini depolar.
  • Depo boyutu zaman içinde büyür.
  • Klonlama, dallanma, getirme ve dal değiştirme işlemleri yavaşlar.

Git'in her sürümün tam içeriğini depolaması gerektiğinden, farklandırma ve sıkıştırma çok işe yaramaz. Bu dosyalar biriktikçe depo büyür, dallanma yavaşlar ve kopyalama süreleri artar.

Büyük ikili kaynak dosyaları için stratejiler

  • Sıkıştırılmış arşivleri işlemeyin. Bunun yerine verilerin sıkıştırmasını kaldırın ve fark edilebilir kaynakları işleyin.
  • Derlenmiş kodu ve diğer ikili bağımlılıkları işlemekten kaçının. Bunları oluşturun veya paket yönetimi aracılığıyla sağlayın.
  • Yapılandırmayı ve diğer yapılandırılmış verileri JSON gibi fark edilebilir düz metin biçimlerinde depolayın.

Git Büyük Dosya Depolama (Git LFS) nedir?

Sürümler arasında çok sık değişen ve önemli ölçüde farklılık gösteren kaynak dosyalar için Git Büyük Dosya Depolama (LFS) kullanın.

Git LFS:

  • Deponuzda tam dosya içeriği yerine büyük dosyalara yönelik işaretçileri depolar.
  • İkili içeriği ayrı bir uzak depolama alanında depolar.
  • Dalları kopyaladığınızda veya değiştirdiğinizde doğru sürümü indirir.
  • Her kopya ve dal değişikliğinde tam dosya içeriğini taşımadan büyük ikili dosyalar için normal Git iş akışınızı korur.

Git LFS avantajları

Git LFS, büyük dosya içeriğini ana depodan taşırken Git iş akışını korur.

  • Ekibiniz aynı uçtan uca Git iş akışını kullanmaya devam edebilir.
  • Büyük dosyalar ana depo geçmişinden uzak kalır ve bu da deponun yönetilebilir kalmasına yardımcı olur.
  • Dosya kilitleme videolar, sesler ve oyun haritaları gibi büyük, fark edilemeyen varlıklar üzerinde paylaşılan çalışmayı destekler.

Azure DevOps Hizmetleri, Git LFS'i tamamen destekler ve ücretsiz olarak sunar. LFS'yi kullanmak için Git LFS istemcisini yükleyin, LFS'de depolamak istediğiniz dosyalar için izlemeyi yapılandırın ve değişikliklerinizi Azure Repos gönderebilirsiniz.

Azure DevOps Server ve Kerberos'a özgü yönergeler için bkz. Kerberos ve Git LFS.

Git LFS sınırlamaları

Git LFS için hâlâ önceden planlanması gereken birkaç ödün vardır:

  • Her Git istemcisiNin Git LFS istemcisini yüklemesi ve izleme yapılandırmasını anlaması gerekir.
  • İstemci yüklenmemiş veya doğru yapılandırılmamışsa, klonlamalar ikili dosyanın kendisi yerine işaretçi verilerini indirir.
  • Git, ikili dosyanın farklı sürümlerini birleştiremediğinden, ekip arkadaşlarının yine de değişiklikleri koordine etmek zorunda olması gerekir.
  • Git LFS dosya kilitleme sağlar, ancak kullanıcıların çalışmaya başlamadan önce yine de en son kopyayı çekmeleri gerekir.
  • Azure Repos, Git LFS izlenen dosyaları olan depolar için Secure Shell'i (SSH) desteklemez.
  • Web arayüzüne bir ikili dosya sürüklemek, LFS işaretçisini değil, ikili dosyanın kendisini repoya commit eder.
  • Büyük yüklemeler, kullanılabilir boş alan, mevcut iş yükü ve bir saatlik yükleme sınırı tarafından sınırlandırılabilir.

Git LFS dosya biçimi

Git LFS izlenen dosyası için deponuza yazdığınız dosyanın her satırda anahtar/değer çifti olan birkaç satırı vardır:

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Uyarı

Azure DevOps Server ve Kerberos için planlama

Azure DevOps Server ve Windows Kimlik Doğrulaması kullanıyorsanız Git LFS kullanırken Kerberos için planlayın. Git LFS 2.10.0 ve üzeri Kerberos kimlik doğrulamayı destekler.

Eski Azure DevOps Server kılavuzunu güncelleştirmeniz gerekiyorsa Kerberos ve Git LFS ile ve bağlantılı Azure DevOps Server kimlik doğrulaması kılavuzuyla başlayın.

İlgili içerik

  • Last updated on