Her yerde bulunan sürüm kontrol sistemi GIT, güçlü yetenekleri ile yazılım geliştirme iş akışlarında devrim yarattı. Kod değişikliklerinin izlenmesini basitleştirir, sorunsuz dallanma ve birleşmeyi sağlar ve sıkı işbirliğini kolaylaştırır. Bugün, 100 milyondan fazla geliştirici Dünya çapında Github platformunu tek başına kullanın.
Ancak, Git her türlü kaynak kodu dosyası yönetimi için her zaman uygun bir çözüm değildir. Git, yazılım projeleri için kaynak kodunu yönetmede mükemmel olsa da, bir geliştirme ortamındaki her dosyaya bağlamak verimsizliklere yol açabilir – üretkenliği bile engelleyebilir.
Her şeyi izleme eğilimi
Git’in varsayılan davranışı, belirli bir depoya eklenen tüm dosyaları izlemektir. Kaynak kodunu izlemenin yanı sıra, yapılandırma dosyalarını da izler, eserler oluşturur ve geçici dosyalar. Hatta istemeden dahil edilmiş olabilecek kişisel notları ve dosyaları izler.
Bu gereksiz izleme, yavaş ve çalışmak için kafa karıştırıcı olabilen şişkin bir depo geçmişiyle sonuçlanır. Depoyu karıştıran çok sayıda özensiz dosyanın varlığı ortasında önemli kod değişiklikleri bulmak zor olabilir.
Dahası, güvenlik riskleri vardır. GIT, şifreler ve API anahtarları gibi yanlışlıkla zor kodlanmış olabilecek hassas bilgileri izleyebilir ve bunları depoya erişimi olanlara maruz bırakabilir. Bazen bunlar Yetkisiz tarafları bile dahil edebilir.
Gereksiz izlemeyi önlemek için, depoya öğe eklerken farkındalık kullanırken, gereksiz dosyalar için depoyu düzenli olarak gözden geçirmeniz tavsiye edilir. Ayrıca, izlemesinden atlaması gereken dosyaları belirtmeyi mümkün kılan bir .Gitignore dosyası oluşturmak çok önemlidir. Bu dosya, Git’i tür ve konuma göre toplu olarak görmezden gelmeye yönlendirebilir.
.Gitignore dosyası Git kullanıcılarının ustalaşması gereken paha biçilmez bir araçtır. Git’e bağlı kalmayı tercih edenler, temel bilgilerin ötesine geçmelidir ve Daha fazlasını keşfedin .gitignore örnekleri. Dosyanın, herhangi bir değer eklemeden dağınıklık oluşturma eğiliminde olan Terraform sağlayıcı ikili dosyalarının ve IDE’ye özgü dosyaların hariç tutulması gibi gelişmiş kullanımları vardır.
Ancak, GIT her kaynak kodu dosyası sürüm yönetimi durumu için en iyi seçenek olmayabilir. GIT’in varsayılan parça davranışını ele almak için hafif ve bağımsız fosil, büyük repository optimize edilmiş mercurial ve merkezi perforce (Helix Core) gibi alternatifleri göz önünde bulundurmak mükemmel bir mantıklı.
Şişkin depolar
“Depo Bloat”, GIT’in sürüm kontrol tasarımının bir sonucu olarak ortaya çıktığı bilinen bir dizi sorunu kapsamaktadır. Depolar aşırı şişirilebilir Git’in yedek veri depolama, aşırı geçmişler ve kazara taahhütlerin etkileri eğilimleri nedeniyle.
Büyük ikili dosyaları içeren bir proje üzerinde çalışan ekipler, her sürüm için ikili bir dosyanın tüm içeriğini sakladığı için Git’e hantal bulacaktır. Örneğin, görüntünün yalnızca birkaç piksel değiştirilmiş veya eklenmiş olsa bile, yeni sürümde aynı 15 MB görüntü olarak 15 MB’lık bir görüntü saklanır. Bu yedeklilik kaçınılmaz olarak birden fazla sürümün yayınlanmasıyla büyük bir depo oluşturur.
Git aşırı tarihler üretmeye eğilimlidir. Bir deponun geçmişi, gerçek değişiklikler minimal olsa bile, her dosyanın, özellikle de büyük olanların her versiyonuyla, aynı heftle ileriye taşınabilir. Ayrıca, dosyalar projeden silinmiş olsa bile, silinen dosyalar, deponun geçmişinde hala mevcut olabileceği için alan almaya devam edebilir.
Ayrıca, Git’in tasarımı kazara taahhütlerin şişkin etkisini daha da kötüleştirir. Geliştiricilerin yanlışlıkla depoda bulunmaması gereken oluşturma artefaktları, veri kümeleri ve geçici dosyalar gibi büyük dosyalar işledikleri zamanlar vardır. Örneğin, 1GB veritabanı dökümü hızlı bir şekilde bir depoyu şişirebilir.
Bu kazara taahhüdü sonunda daha sonraki bir taahhütte düzeltilse bile, büyük dosya deponun geçmişinde var olmaya devam edecektir, bu da aynı şekilde potansiyel olarak tehlikeli veri gizliliği sonuçları.
Depolama maliyetlerini ve hassas veri maruziyet tehlikelerini artırmanın yanı sıra, şişkin depolar, getirme, itme, dallanma, klonlama ve birleştirme gibi git işlemlerinin yavaşlamasıyla durgun iş akışlarına neden olur. Bu yavaş performans ve verimlilik, geliştirme verimliliğini etkiler. Dahası, şişkin depo geçmişleri bir projeyi anlamayı zorlaştırır. Dağınıklık ve gereksiz dosyaların varlığı depo navigasyon ve yönetimini şaşırtmaktadır.
Veri maruz kalma riskleri
GIT, güvenli kaynak kodu yönetimini sağlamaya yardımcı olan veri bütünlüğü, ademi merkeziyeti ve erişim kontrol özellikleri ile dikkat çekiyor. Ancak, doğal olarak kusursuz değildir. Diğer herhangi bir çözüm gibi, güvenliği de büyük ölçüde nasıl kullanıldığına ve güvenlik uygulamalarına bağlıdır.
Varsayılan her şey işlevinden dolayı GIT, havuza erişimi olan herkese şifreleri, API anahtarlarını veya özel sertifikaları yanlışlıkla ortaya çıkarabilir. Kazara taahhütler bu hassas bilgileri yetkisiz bireylere bile maruz bırakabilir.
Bu arada, depoların şişkinliği saldırı yüzeylerinin genişlemesini etkiliyor. Yönetilmesi daha zordur, bu nedenle güvenlik sorunlarını tespit etmek ve çözmek zorlaşır. Örneğin, geliştiriciler yanlışlıkla hassas veriler içeren dahili belgeler veya hata ayıklama günlükleri yapabilirler. Bu hataları bulmak zaman alabilir veya asla keşfedilmeyebilir.
Ayrıca, şişirilmiş depolar, güvenlik özelliklerini devre dışı bırakan veya SQL enjeksiyonu ve bölgeler arası komut dosyası güvenlik açıklarına neden olan kazara değişiklikler gibi güvenlik ile ilgili hataların riskini artırabilir. Ayrıca, yetkisiz kullanıcılara erişim sağlayan yanlış izinlerle işlenen dosya durumları da vardır.
Ayrı depoların kullanılması
Bazı projeler için, bazı dosya türleri için git kullanmaya devam etmek ve diğer dosya türleri için ayrı depolar olabilir.
Örneğin, bir proje şema değişikliklerini yönetmek için özel bir veritabanı deposu ve belgeler için ayrı bir depoya sahip olabilir. Medya dosyaları bulut tabanlı bir varlık yönetim sistemi aracılığıyla ayrı olarak yönetilebilir. Bu unsurları nasıl idare ediyorsunuz, Kuruluşunuz DevOps’u Nasıl İşliyor.
Amazon S3, Google Cloud depolama ve Azure Blob Storage, büyük dosyaları ve medya varlıklarını depolamak için uygun maliyetli olan ölçeklenebilir çözümler sunar. Bu hizmetler sağlam güvenlik özellikleri ve verimli veri alma mekanizmaları ile birlikte gelir.
Git’i medya dosyaları, belgeler ve dosya türleri için ayrı depolarla kullanmak yaygın bir uygulamadır. Bunu yapmak, depo şişmanlığı ve GIT ile ilişkili verimsiz ikili dosya yönetimi sorunlarını etkili bir şekilde ele almaktadır.
Git, modern yazılım geliştirme için vazgeçilmez bir araç olmaya devam ediyor. Bununla birlikte, depo şişkinliği, gelişigüzel dosya izleme ve güvenlik sorunları ortaya çıktığında kullanmaya devam etmek verimsiz olacaktır. .Gitignore dosyası bu endişeleri gidermek için iyi bir yoldur, ancak bazı ekipler alternatifleri kullanmayı veya Git’i büyük dosyalar için ayrı depolarla kullanmayı daha kolay bulabilir.
Neden bazı kaynak kodu dosyalarının GIT tabanlı sürüm kontrolü aracılığıyla yönetilmemesi gerektiği yazı, BT Security Guru’da ilk olarak ortaya çıktı.