Kopyalanmış depoların boyutunu yönetmek için Git geçmişinizden büyük bir ikili dosyayı kaldırmayı öğrenin

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git, son yıllarda kullanıcıların bağlantısı kesilmiş durumdayken tam depoyla çalışmasını sağlayan dağıtılmış bir kaynak kodu deposu olarak çok popülerlik kazanmıştır. Git'in avantajları iyi belgelenmiştir, ancak birincil depoda "saati geri almanız" gerekirse ne olur? Bunu yapmak çok sezgisel değildir ve deponun her bir kullanıcısını etkileyen bir şey için bekleyebileceğiniz gibi yükseltilmiş izinler gerektirir.

Peki merkezi depoyu nasıl güvenli bir şekilde geri alabilirsiniz?

Sorun Senaryosu

Git sunucunuza video gibi büyük bir dosya işlediğinizi düşünün. Geleneksel bir kaynak kodu sisteminde, her şeyi tek bir yerde depolamak ve sonra ihtiyacınız olanı aşağı çekmek uygundur. Ancak git ile deponun tamamı her kullanıcının yerel bilgisayarına kopyalanır. Büyük bir dosyayla, projedeki her kullanıcının büyük dosyaları da indirmesi gerekir. Her yeni büyük dosya sunucuya işlendiğinde, sorun yalnızca büyümeye devam eder ve sonunda depo kullanıcıları için verimli olamayacak kadar büyük hale gelir. Daha da kötüsü, suçluyu yerel deponuzdan kaldırıp yeniden başlatsanız bile, dosya deponun geçmişinde var olmaya devam eder ve bu da geçmişin bir parçası olarak herkesin yerel bilgisayarına indirileceği anlamına gelir.

Takım Gezgini Değişiklikleri iletişim kutusu, eklenen değişikliklerde büyük bir video gösteriyor.

Yerel depoya büyük dosya ekleme

Yerel depodan işledikten sonra, sunucuda büyük dosya da olur

Depoyu dondurun

Önemli

Aşağıdaki adımlar videoyu dal geçmişinizden kaldırır, ancak deponuzu Azure Repos'tan kopyaladığınızda dosya depo geçmişinizde kalır. Dosyaların dal geçmişinizden kaldırılması, dosyaların güncelleştirilmesini önler ve bu da deponuzda büyük dosyanın başka bir sürümünü oluşturur. Git'te büyük dosyaları yönetme hakkında daha fazla bilgi edinin ve Azure Repos Git depolarını kullanırken bu davranışla ilgili ayrıntılı bir açıklama ve geçici çözüm için bu blog gönderisini inceleyin.

Bunu düzeltmek için kaynaktan başlamanız gerekir; bu örnekte sunucu deposudur. Ekipten depoya göndermeyi durdurmasını isteyin, ancak bu işlem sırasında ek gönderimler olursa, veri kaybetmemek için bunları da hesaba katmak zorunda olursunuz.

Yeniden temel oluştur ve zorla gönder

Ekipteki başka hiç kimse depoda herhangi bir değişiklik yapmadıysa (genellikle gönderim yoluyla), yerel deponuzun istediğiniz gibi görünmesini sağladığınız (yani büyük dosya olmadan) kolay yolu izleyebilir, ardından değişikliklerinizi sunucuda zorlayabilirsiniz.

Not: Bu çalışmaya başlamadan önce yerel deponuzu kopyalamanız veya düzeltmeniz gerekebilir. Bu, çalışmanın veya değişikliklerin kaybolmasına neden olabileceğinden dikkatli olun.

Varsayılan olarak, büyük olasılıkla yalnızca yerel proje dosyalarını ve depolarını değiştirebilir ve değişikliklerinizi sunucuya gönderebilirsiniz, böylece silme veya yeniden dengeleme gibi diğer değişiklikleri sunucu düzeyinde yapamazsınız. Bu nedenle, yöneticinizden proje Zorlamalı gönderim (tercih edilen) veya yönetici izinleri almanız ya da bunlara sahip olan ve yardım etmek isteyen birini bulmanız gerekir. Git izinleri hakkında daha fazla bilgi için buraya gidin.

Ardından depoyu yeniden temel almanız gerekir.

1. Ancak ilk olarak, en son işlemelerin SHA karma değerlerini bulmak için kullanın git log . Bu bilgiye hemen ihtiyacınız olacak. Bunun nedeni, en son iyi taahhüdü bilmemiz gerektiğidir. Git komut istemini açıp yazarak bu bilgileri alırsınız:

git log

Alternatif olarak, Visual Studio Ekip Gezgini'nde dal geçmişini görüntüleyerek SHA karması alabilirsiniz.

2. Şimdi bir Git komut istemi açın.

3. İlgi alanı SHA karması sayısını bulun.

4. "25b4" ile başlayan sha'ya ihtiyacınız olacak

Git'in depoda baş veya geçerli dalın nerede bulunduğunu belirlemek için işaretçiler kullandığını unutmayın. Bu nedenle, ilgilendiğiniz depo durumu geçmişte bir noktada olacaktır. 'Zamana geri dönmek' ve bu önceki istenen durumu yeni geçerli duruma getirmek için git rebase komutunu kullanmanız gerekir:

git rebase -i <SHA hash of desired new current branch>

Anahtar -i, geçmişi bir düzenleyicide açacağı için biraz daha fazla güvenlik sağlar (Windows'daki komut satırında git uygulamam, Unix tabanlı bir sistemle çalıştıysanız hatırlayabileceğiniz klasik vi düzenleyicisini açar.)

5. Örneğimiz için şunu girersiniz:

git rebase -i 25b4

6. Düzenleyici geldikten sonra, yeni kafa olarak tutmak istediğiniz dal dışındaki tüm 'pick' satırlarını kaldırın. Her şey istediğiniz gibi göründüğünde, vi'ye kaydetmek için ":w<enter>" yazın veya kaydetmeden çıkmak için "!q<enter>" yazın.

Artık istemediğiniz satırları değiştireceksiniz

7. Gösterildiği gibi "pick" öğesini "drop" olarak değiştirin, ardından kaydetmek için ":w" (vi) yazıp rebase'i başlatmak için ":q!" yazın.

Şimdi yeniden yazın git log . Sorunlu dal günlükte bulunmamalıdır. Bu durumda proje yöneticisi izinleri gerektiren son adıma hazırsınız demektir.

git log

Büyük video yüklemesinin artık yerel repoda olmadığını fark edin

8. Tür: git push --force

Bu komut, deponuzu sunucudaki deponun üzerine yazmaya zorlar.

Sunucudaki verileri kolayca kaybedebileceğiniz için dikkatli olun!!

Bunun çalışması için sunucuda kimlik doğrulaması yapmanız gerektiğine dikkat edin

Azure Repos kullanıyorsanız, özel karakterler (e-posta adresinde "@" gibi) kullanmayan alternatif bir kimlik bilgisi ayarlamanız gerekebilir. Bunu yapmak için buradaki yönergeleri izleyin.

Artık dal sunucudan kalıcı olarak kaldırılır ve proje ekibi üyeleri tarafından yapılan sonraki kopya ve eşitlemeler, kaldırmaya çalıştığınız büyük dosyaları indirmez. Kullanıcıların yeni sunucu deposu durumuyla eşitlenmiş olduklarından emin olmak için sunucudan çekmeleri gerekir.

Kullanıcıların Daha Yeni Commit'leri Varsa

Diğer kullanıcılar sunucu deposuna zaten bağlıysa, ek bir değerlendirmeniz vardır. Büyük dosyaları içeren dalı kaldırmak istiyorsunuz, ancak ekibin yaptığı değişiklikleri kaybetmek istemiyorsunuz. Bu sorunu çözmek için, yeniden taban oluşturmanın bir parçası olarak düzenleyiciyi açtığınızda commitlere dikkatlice bakın. Korumak istediğiniz işlemelerin 'pick' satırlarında listelenmiş olduğundan emin olun; büyük bir dosyanın eklendiği yer gibi kaldırmak istediklerinizi silin.

Yeniden dengeleme sonrasında ekipte yer alan diğer kullanıcıların da sunucu deposunun tutarlı bir kopyasına sahip olması için yeniden temel almaları gerektiğini unutmayın. Bu herkes için bir acıdır ve normalde kaçınılmalıdır. Bu nedenle, burada belirtildiği gibi bir push bildirimi kaldırmanız gerekiyorsa, ekip ile koordinasyon sağlamak önemlidir. Yeniden boyutlandırmayla ilgili tüm ayrıntılar için buradaki resmi yeniden boyutlandırma belgelerine göz atın.

Anahtar, hangi işlemelerin istendiğini ve istenmediğini bildiğinizden emin olmaktır. Git günlüğünü veya IDE'nizdeki (Visual Studio gibi) geçmişi inceleyin ve hangi SHA karmalarının tutulup hangilerinin atılacağını dikkatle not edin.

Büyük dosyanın bir süredir mevcut olduğu ve sonraki dalların ve birleştirmelerin bulunduğu senaryolarda, git filter-branch seçeneğini kullanarak dosyayı kaldırabilirsiniz. Bunu denemek istiyorsanız buradaki yönergeleri izleyin.

En İyi Uygulamalarda Dikkat Edilmesi Gerekenler

Büyük dosyaların ilk etapta ana depodan uzak kalmasını sağlamak için çok fazla çalışma tasarrufu sağlar. Bunu göz önünde bulundurarak, takımın göz önünde bulundurması gereken bazı sağduyu en iyi yöntemleri aşağıda bulabilirsiniz:

Yapılması Gerekenler

• Değişiklikleri sık sık işleyin. Bunları daha sonra squash veya yeniden düzenleme ile düzeltebilirsiniz.
• Değişikliklerinizi yalıtmak için dalları kullanın. Dallar ucuz ve özeldir ve birleştirme basittir. Ayrıca, bir daldaki değişiklikleri sunucuya göndererek de yedekleyebilirsiniz.
• Konu dallarını yayımlarken adlandırma kuralı kullanın. Dalı "users/<alias>/<branchname>" olarak adlandırın. Bu, dallarınızı gruplandırmaya yardımcı olur ve başkalarının "sahibi" tanımlamasını kolaylaştırır.
• Değişikliklerinizi göndermeyi unutmayın. Commit != Checkin. (Commit + Push) == Checkin.
• Depoya eklenmemeleri için büyük ikili dosyaları kullanmayı .gitignore göz önünde bulundurun. Burada daha fazla bilgi bulabilirsiniz.
• Büyük ikili dosyaları depolamak için NuGet veya TFS sürüm denetimini kullanmayı göz önünde bulundurun.

Yapılmaması Gerekenler

• Gönderim yaptıktan sonra yeniden temel atma (rebase) yapmayın. Git'te gönderilen işlemeleri yeniden boyutlandırmak kötü olabilir çünkü depodaki diğer herkesi yerel değişikliklerini yeniden temellendirmeye zorlar ve bunu yapması gerektiğinde mutlu olmazlar. Başka kişiler bu işlemeleri çekmediği sürece, gönderilen işlemeleri kendi kişisel dalınız üzerinde yeniden boyutlandırmak, gönderilse bile önemli bir anlaşma değildir.
• deponuza ikili dosya işlemeyin. Git, ikili dosyaları TFVC'nin yaptığı gibi sıkıştırmaz ve tüm depolar tüm geçmişe sahip olduğundan, ikili dosyaların işlenmesi kalıcı şişkinlik anlamına gelir.

Özet

Bazen, büyük dosyalar gibi istenmeyen öğeler bir depoya eklenir ve depoyu temiz ve hafif tutmak için kaldırılması gerekir. Bunu yapmak için komutunu kullanarak git rebase yerel deponuzu sırayla alabilir ve ardından komutunu kullanarak git push --force sunucu deponuzun üzerine yerel deponuzun üzerine yazabilirsiniz.

Yazarlar: Edward Fry ve Jesse Houwing | Yazarlar ve ALM ile bağlantı kurma | DevOps Rangers burada

(c) 2015 Microsoft Corporation. Tüm rights reserved.ÿBu belge "as-is" sağlanır. URL ve diğer İnternet Web sitesi başvuruları da dahil olmak üzere bu belgede ifade edilen bilgiler ve görünümler bildirimde bulunmadan değişebilir. Kullanım riski size aittir.

Bu belge size herhangi bir Microsoft ürünündeki herhangi bir fikri mülkiyet için herhangi bir yasal hak sağlamaz. Bu belgeyi iç ve başvuru amacıyla kopyalayabilir ve kullanabilirsiniz.