Aracılığıyla paylaş

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şi aktaracak mısınız ve nasıl aktaracaksınız 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 teslim etmeden önce gerekli kod gözden geçirmeleri. Git dallanma modelinde pull request 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çin

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 zorlaşana kadar birleştirmelerin gecikmesine yol açan yalıtılmış ve uzun ömürlü özellik dallarını teşvik etmez. 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ı, taşınması 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.

Karar ver: Geçmişin taşınıp taşınmayacağına

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 geçmişinin tamamını geçirmeyi iddia eder. Git taahhüdü, önceki sürüm kontrol aracının kullandığı değişiklik kümesi veya check-in modeline nispeten iyi eşleşiyor 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 yalnızca en son dal sürümünün anlık görüntüsünü Git'e getiren bir tip geçişi yapması gerekir. Çoğu ekip için zaman, geçiş sırasında daha yüksek yatırım getirisi sağlayan süreçlerin iyileştirilmesi gibi alanlarda harcanmalı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. İzler, bir proje taşındıktan sonra çalışmaya başlayan ve eski versiyon kontrol 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 sağlama

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.

İnsanlar farklı şekillerde öğrenir, bu nedenle ç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:

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 et

Ekipler işlemlerini güncelleştirdikten, kodlarını analiz ettikten ve üyelerini eğitdikten sonra kaynak kodu geçirmenin zamanı geldi. Uç geçişi veya geçmişi yapsanız da yapmasanız da, 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çiyor.
  • Tüm dallar kullanılabilir.
  • Depoda boş ikili dosya yok.
  • Kullanıcılar getirmek ve göndermek için uygun izinlere sahiptir.
  • Derleme işlemleri başarılı olur ve tüm testler başarıyla geçer.

Kodu taşı

Son geçişi çalışma dışı saatlerde, ideal olarak doğal bir durgunluk döneminde önemli aşamalar 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 fazla sistemi paralel olarak çalıştırmaya çalışmak, geliştiricilerin kodlarını nerede veya nasıl entegre edeceklerini bilmemeleri 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'nden geçiş hakkında bilgi için bkz. TFVC'den Git'e geçiş.

Geçiş denetim listesi

Ekip iş akışları:

  • Yapıların nasıl çalıştırılacağını belirleyin.
  • Testlerin ne zaman çalıştırılacağına karar verin.
  • Bir yayın yönetimi süreci geliştirin.
  • Kod değerlendirmelerini pull request'lere taşıyın.

Dallanma stratejisi:

  • Git dallanma stratejisini seçin.
  • Dallanma stratejisini, neden seçildiğini ve önceki dalların nasıl eşlendiğini belgeleyin.

History:

  • Eski sürüm denetiminin ne kadar süreyle çalışır durumda tutuleceğine karar verin.
  • Taşınması gereken şubeleri/birimleri tanımlayın.
  • Gerekirse, mühendislerin eski sisteme geri dönmesine yardımcı olmak için navigasyon izleri oluşturun.

İkili dosyalar ve araçlar:

  • Depodan kaldırılacak ikili dosyaları ve fark edilemeyen dosyaları belirleyin.
  • Git-LFS gibi büyük dosyalar için bir yaklaşım belirleyin.
  • NuGet gibi araçları ve kitaplıkları teslim etmek için bir yaklaşım belirleyin.

Eğitim:

  • Eğitim malzemelerini tanımlama.
  • Eğitim etkinlikleri, yazılı malzemeler ve videolar planlayın.
  • Yerel Git uzmanları olarak görev yapmak için ekibin üyelerini belirleyin.

Kod geçişi:

  • Geçişin sorunsuz bir şekilde ilerlemesini sağlamak için birden çok test çalıştırması yapın.
  • Kesinti zamanını belirleyin ve bildirin.
  • Yeni Git deposunu oluşturun.
  • Eski sistemi salt okunur olarak ayarlayın.
  • İlk olarak ana dalı taşıyın, ardından diğer gerekli dalları taşıyın.

Sonraki Adımlar

  • Last updated on