Merkezi sürüm denetiminden Git'e geçiş

Merkezi sürüm denetiminden ekibi Git'e geçirmek için yeni komutları öğrenmekten fazlası gerekir. Git, dağıtılmış geliştirmeyi desteklemek için dosya geçmişini ve dal bilgilerini merkezi bir sürüm denetim sisteminden farklı şekilde depolar. Merkezi bir sürüm denetim sisteminden Git'e başarılı bir geçiş planlamak ve uygulamak için bu temel farklılıkların anlaşılması gerekir.

Microsoft, birçok iç ekibin ve müşterinin merkezi sürüm denetim sistemlerinden Git'e geçirilmesine yardımcı oldu. Bu deneyim, tutarlı bir şekilde başarılı olan uygulamalara dayalı olarak aşağıdaki kılavuzu üretmiştir.

Başarılı geçiş adımları

Başarılı bir geçiş için ekiplerin şunları yapması gerekir:

• Geçerli araçları ve işlemleri değerlendirin.
• Git dallanma stratejisini seçin.
• Geçmişin geçirilip geçirilip geçirmeyeceğine ve nasıl geçirilip geçirmeyeceğine karar verin.
• Önceki sürüm denetim sistemini koruyun.
• kaynak denetiminden ikili dosyaları, yürütülebilir dosyaları ve araçları kaldırın.
• Git kavramları ve uygulamalarında ekipleri eğitin.
• Git'e geçişi test edin.

Geçerli araçları ve işlemleri değerlendirme

Sürüm denetim sistemlerinin değiştirilmesi, yeni araçlar ve uygulamalarla geliştirme iş akışını doğal olarak kesintiye uğratır. Bu kesinti, DevOps işleminin diğer yönlerini geliştirmek için bir fırsat olabilir.

Ekipler yeni sisteme geçiş yaptıklarında aşağıdaki uygulamaları benimsemeyi göz önünde bulundurmalıdır:

• Sürekli tümleştirme (CI),her iadenin derleme ve test geçişlerini tetiklediği yerdir. CI, hataların erken belirlenmesine yardımcı olur ve projeler için güçlü bir güvenlik ağı sağlar.

• Kodu denetlemeden önce gerekli kod gözden geçirmeleri . Git dallanma modelinde, çekme isteği kod incelemesi geliştirme sürecinin bir parçasıdır. Kod gözden geçirmeleri CI iş akışını tamamlar.

• Dağıtım işlemlerini otomatikleştirmek için sürekli teslim (CD). Sürüm denetimi araçlarını değiştirmek için dağıtım işlemi değişiklikleri gerekir, bu nedenle geçiş, modern bir yayın işlem hattını benimsemek için iyi bir zamandır.

Git dallanma stratejisi seçme

Kodu geçirmeden önce ekibin bir dallanma stratejisi seçmesi gerekir.

Git'te, kısa süreli konu dalları geliştiricilerin ana dala yakın çalışmalarına ve birleştirme sorunlarından kaçınarak hızla tümleştirmelerine olanak sağlar. GitFlow ve daha basit bir çeşitleme olan GitHub Flow, yaygın olarak kullanılan iki dal stratejisidir.

Git, tümleştirme zor olana kadar birleştirmeleri geciktirme eğilimi gösteren uzun ömürlü, yalıtılmış özellik dallarını önerilmez. Ekipler, özellik bayrakları gibi modern CD tekniklerini kullanarak kodu ana dala hızla tümleştirebilir, ancak tamamlanana kadar devam eden özellikleri kullanıcılardan gizler.

Şu anda uzun ömürlü bir özellik dalı stratejisi kullanan ekipler Git'e geçmeden önce özellik bayraklarını benimseyebilir. Özellik bayraklarının kullanılması, geçirilmesi gereken dal sayısını en aza indirerek geçişi basitleştirir. İster özellik dalları ister özellik bayrakları kullansın, ekiplerin eski dallarla yeni Git dalları arasındaki eşlemeyi belgelemesi gerekir; böylece herkes yeni çalışmalarını nereye işleyebileceğinizi anlayabilir.

Geçmişin geçirilip geçirmeyeceğine karar verme

Teams mevcut kaynak kodu geçmişini Git'e geçirmek isteyebilir. Çeşitli araçlar, merkezi bir araçtan Git'e tüm dalların tam geçmişini geçirmeyi iddia eder. Git işlemesi, önceki sürüm denetim aracının kullandığı değişiklik kümesine veya iade etme modeline göre daha iyi eşleniyor gibi görünür.

Ancak bu eşlemenin bazı ciddi sınırlamaları vardır.

• Çoğu merkezi sürüm denetim sisteminde, dallar depoda klasör olarak bulunur. Örneğin, ana dal /trunk adlı bir klasör olabilir ve diğer dallar /branch/one ve /branch/two gibi klasörlerdir. Git deposundaki dallar deponun tamamını içerdiğinden 1:1 çevirisi zor olur.

• Bazı sürüm denetim sistemlerinde etiket veya etiket, ağaçtaki çeşitli dosyaları, hatta farklı sürümlerdeki dosyaları içerebilen bir koleksiyondur. Git'te etiket, deponun tamamının belirli bir zaman noktasındaki anlık görüntüsüdür. Etiket, deponun bir alt kümesini temsil edebilir veya farklı sürümlerde dosyaları birleştiremez.

• Çoğu sürüm denetim sistemi, yeniden adlandırma, geri alma ve geri alma gibi ayrıntılı değişiklik türleri de dahil olmak üzere dosyaların sürümler arasında nasıl değiştiğiyle ilgili ayrıntıları depolar. Git, sürümleri deponun tamamının anlık görüntüleri olarak depolar ve dosyaların değiştirilme şekliyle ilgili meta veriler kullanılamaz.

Bu farklılıklar, tam geçmiş geçişinin en iyi ihtimalle kayıplı ve muhtemelen yanıltıcı olacağı anlamına gelir. Kayıp, harcanan çaba ve geçmişi kullanmanın göreli nadirliği göz önünde bulundurulduğunda, çoğu ekibin geçmişi içeri aktarmaktan kaçınması önerilir. Bunun yerine, ekiplerin git'e yalnızca en son dal sürümünün anlık görüntüsünü getiren bir ipucu geçişi yapması gerekir. Çoğu ekip için zaman, geçişin daha yüksek yatırım getirisi olan alanlara (süreçleri geliştirme gibi) harcanmasıdır.

Eski sürüm denetim sistemini koruma

Geçiş sırasında ve sonrasında geliştiricilerin önceki sürüm denetim geçmişine erişmesi gerekebilir. Önceki sürüm denetimi geçmişi zaman içinde daha az ilgili hale gelse de, buna başvurabilmek yine de önemlidir. Yüksek düzeyde düzenlenmiş ortamlar, sürüm denetimi geçmişi için belirli yasal ve denetim gereksinimlerine sahip olabilir.

Özellikle yalnızca ipucu geçişi gerçekleştiren ekipler için, önceki sistemin süresiz olarak korunması kesinlikle önerilir. Geçiş yaptıktan sonra eski sürüm denetim sistemini salt okunur olarak ayarlayın.

Büyük geliştirme ekipleri ve düzenlenmiş ortamlar Git'e eski sürüm denetim sistemine işaret eden içerik haritaları yerleştirebilir. Basit bir örnek, ipucu geçişi öncesinde Git deposunun köküne ilk işleme olarak eklenen ve eski sürüm denetim sunucusunun URL'sine işaret eden bir metin dosyasıdır. Birçok dal geçirildiyse, her daldaki bir metin dosyası, dalların eski sistemden nasıl geçirıldığını açıklamalıdır. İçerik haritaları, geçirildikten sonra bir proje üzerinde çalışmaya başlayan ve eski sürüm denetim sistemi hakkında bilgi sahibi olmayan geliştiriciler için de yararlıdır.

İkili dosyaları ve araçları kaldırma

Git'in depolama modeli, kısa ve yüksek oranda sıkıştırılabilir metin dosyalarının ve kaynak kodunun sürüm oluşturması için iyileştirilmiştir. İkili dosyalar genellikle büyüktür ve bir depoya eklendikten sonra depo geçmişinde ve gelecekteki her kopyada kalırlar. Git'in geçmişi depolama şekli nedeniyle geliştiriciler depolara ikili dosya eklemekten kaçınmalı, özellikle de çok büyük olan veya sık değişen ikili dosyalar. Git'e geçiş yapmak, bu ikili dosyaları kod tabanından kaldırma fırsatıdır.

Ayrıca kitaplıkların, araçların ve derleme çıktılarının depolardan dışlanması önerilir. Bunun yerine, bağımlılıkları yönetmek için NuGet gibi paket yönetim sistemlerini kullanın.

Simgeler ve resimler gibi varlıkların kaynak kodun belirli bir sürümüyle uyumlu olması gerekebilir. Simgeler gibi küçük, seyrek değiştirilen varlıklar geçmişi şişirmeyecek ve bunları doğrudan bir depoya ekleyebilirsiniz. Büyük veya sık değişen varlıkları depolamak için Git Büyük Dosya Depolama (LFS) uzantısını kullanın. GitHub'da büyük dosyaları yönetme hakkında daha fazla bilgi için bkz . Büyük dosyaları yönetme. Azure Repos için bkz . Git'te büyük dosyaları yönetme ve depolama.

Eğitim verme

Git'e geçişteki en büyük zorluklardan biri, geliştiricilerin Git'in değişiklikleri nasıl depoladığını ve işlemelerin geliştirme geçmişini nasıl oluşturacaklarını anlamasına yardımcı olmaktır. Eski komutları Git komutlarına eşleyen bir bilgi sayfası hazırlamak yeterli değildir. Geliştiricilerin merkezi, doğrusal bir model açısından sürüm denetimi geçmişini düşünmeyi bırakması ve Git'in geçmiş modelini ve işleme grafiğini anlaması gerekir.

Kişiler farklı yöntemlerle bilgi edindiğinizden, çeşitli eğitim malzemeleri sağlamanız gerekir. Uzman bir eğitmenle canlı, laboratuvar tabanlı eğitim, bazı kişiler için iyi çalışır. Pro Git kitabı, çevrimiçi olarak ücretsiz olarak sunulan mükemmel bir başlangıç noktasıdır.

Ücretsiz uygulamalı eğitim kursları şunlardır:

• Git öğrenme yolu ile sürüm denetimine giriş.
• Azure Repos'ta Git'i kullanmaya başlama hızlı başlangıcı.
• GitHub'ın Git ve GitHub öğrenme kaynakları.

Kuruluşlar ekipler üzerindeki Git uzmanlarını belirlemek, başkalarına yardımcı olmaları için onları güçlendirmek ve diğer ekip üyelerini onlara soru sormaya teşvik etmek için çalışmalıdır.

Geçişi test edin

Ekipler işlemlerini güncelleştirdikten, kodlarını analiz ettikten ve üyelerini eğitdikten sonra kaynak kodu geçirmenin zamanı geldi. İpucu geçişi veya geçiş geçmişi yapmanız fark etmeksizin, bir test deposuna bir veya daha fazla test geçişi yapmak önemlidir. Son geçişi gerçekleştirmeden önce şunları yaptığınızdan emin olun:

• Tüm kod dosyaları geçirildi.
• Tüm dallar kullanılabilir.
• Depoda boş ikili dosya yok.
• Kullanıcılar getirmek ve göndermek için uygun izinlere sahiptir.
• Derlemeler başarılı olur ve tüm testler geçer.

Kodu geçirme

Son geçişi çalışma dışı saatlerde, ideal olarak doğal kapalı kalma süresi olduğunda kilometre taşları arasında yapın. Geliştiriciler çalışmayı bitirmeye çalışırken sprint'in sonunda geçiş yapmak sorunlara neden olabilir. Kimsenin giriş yapması gerekmeyen bir hafta sonu geçiş yapmayı deneyin.

Eski sürüm kontrol sisteminden Git'e sıkı bir tam geçiş planlayın. Birden çok sistemi paralel olarak çalıştırmaya çalışmak, geliştiricilerin nerede veya nasıl iade yapılacağını bilmediği anlamına gelir. Karışıklığı önlemek için eski sürüm denetim sistemini salt okunur olarak ayarlayın. Bu koruma olmadan, geçici değişiklikler içeren ikinci bir geçiş gerekebilir.

Gerçek geçiş işlemi, geçiş yaptığınız sisteme bağlı olarak değişir. Team Foundation Sürüm Denetimi geçiş hakkında bilgi için bkz. TFVC'den Git'e geçiş.

Geçiş denetim listesi

Ekip iş akışları:

Dallanma stratejisi:

Geçmiş:

İkili dosyalar ve araçlar:

Eğitim:

Kod geçişi:

Sonraki adımlar

• Team Foundation Server'dan Azure DevOps'a geçiş
• TFVC komutları ve iş akışı Git ile nasıl eşler?