Kod akışı stratejisi seçme
Ekibinizin çalışma şekline uygun bir kod akışı stratejisi seçmek önemlidir. Dikkate almanız gereken çeşitli stratejiler vardır. Modülün sonunda seçenekleri keşfedebilirsiniz. Tailspin web ekibi, Git ve GitHub'ı temel alan bir kod akışı stratejisi geliştirmeye karar verir.
Mara, Azure Boards'ı kurduğunda, o ve ekip ele alınması gereken birkaç ilk görev belirledi. Görevlerden biri Git tabanlı bir iş akışı oluşturmaktı.
Birlikte çalışmak için daha iyi bir yol üzerinde çalıştıkları için ekibi dinleyelim. Şu anda merkezi bir sürüm denetim sistemi kullanıyorlar ancak plan, dağıtılmış bir sistem olan Git'e geçmektir.
Mara, Andy içeri girdiğinde kendisine atanan özellikler üzerinde titizlikle çalışıyor.
Merhaba Mara. Bu sabahki liderlik toplantısında ekibimizin ve oyun geliştirme ekibimizin farklı sürüm kontrol sistemleri kullandığı ortaya çıktı. Kaynakları ekipler arasında paylaşma şeklimizi kolaylaştırmak için, işbirliğini daha iyi işleyebilen dağıtılmış bir sürüm denetimi sistemine geçmemiz istendi.
Bunu bilmek güzel. Hatırlarsan, tahtamıza koyarız. Şu anda merkezi bir sürüm denetimi sistemi kullanıyoruz. Şu anda bizim için harika çalışıyor, ancak dağıtılmış bir sürüm denetim sisteminin ekipler arasında paylaşmaya başladığımızda daha iyi bir seçim olduğunu ve ekibimizin büyüdüğünü kabul ediyorum. Ayrıca, tüm paydaşların herkesin ne yaptığını bilmesi için görünürlüğü artırmak da panomuzda yer alan bir görevdir. Git gibi dağıtılmış bir kaynak denetim sisteminin de yardımcı olacağını düşünüyorum.
Bir süredir Git'i denemek istiyorum. Hiç zamanım olmadı. Öğrenmek veya ayarlamak zor mu? Mantıklı görünüyorsa, belki şimdi üzerinde çalışabiliriz. Her zaman bir şeyleri devre dışı bırakmaktan bıktım. Ve herkesin ne yaptığını görebilmek ve deponun tamamına erişebilmek güzel olurdu. Tamam, tüm bunlar neyle ilgili?
İzin ver açıklayayım, sonra da hemen uygulamak istediğimiz bir şeye ben karar verelim.
Mara ve Andy, sürüm denetimiyle ilgili bir tartışma için beyaz tahtaya geçer.
Git ve dağıtılmış sürüm denetimi nedir?
Mara: Soldaki çizim, şu anda kullandığımız gibi merkezi sürüm denetimidir. kod tabanının 
herkesin kullandığı Team Foundation Sürüm Denetimi (TFVC) merkezi bir sürümüne sahibiz. Her birimiz değiştirmemiz gereken dosyalar üzerinde çalışır ve sonra bunları bitirdiğimizde ana depoda yeniden birleştiririz.
Evet, bu bizim için işe yarıyor. Tek fark, bir değişikliğin merkezi depoda birleştirilmesiyle engellendiğim zamandı.
Mara: Doğru! engellendiniz 
. Engelleme sorununu çözmek için TFVC ile bir dallanma stratejisi kullanabiliriz, ancak geçerli yapılandırmamızda birleştirme biraz daha karmaşık hale gelebilir. Ve bu hataya neden olan değişikliği 
yaptığımızda, biz bu çözüme varana kadar kimse hiçbir işi halledemez. Hepimiz kodun aynı kopyasını kullandığımız için bu sorun her zaman gizleniyor.
Sağ tarafta dağıtılmış sürüm denetiminin çizimi yer alır. Hala kod tabanının kararlı sürümü olan merkezi bir depomuz 
var, ancak her geliştiricinin çalışması gereken kendi kopyası 
var. Bu, merkezi depoyu etkilemeden çeşitli yaklaşımları denememizi ve denememizi sağlar.
Dağıtılmış sürüm denetimi, yalnızca çalışma kodunun 
merkezi depoda birleştirilmesini de sağlar. Hatta kodun gözden geçirilinceye kadar birleştirilememesi için bile ayarlayabiliriz.
Azure DevOps'un en iyi yanı, hem merkezi sürüm denetimi sistemleri hem de dağıtılmış sürüm denetimi sistemleriyle iyi çalışmasıdır.
Andy: Birden fazla kişi aynı dosyayı değiştirdiğinde ne olur?
Mara: Git çoğu zaman birden çok değişikliği otomatik olarak birleştirebilir. Elbette, her zaman değişikliklerin bileşiminin çalışan kodla sonuçlanmasını sağlamak istiyoruz. Git değişiklikleri otomatik olarak birleştiremezse, çakışmaları doğrudan dosyalarda işaretler, böylece bir insan hangi değişiklikleri kabul etmek istediğinizi seçebilir.
Andy: Şu anda kodumuz kendi sunucumuzda depolanır. Dağıtılmış sürüm denetimini kullanmaya geçersek kod nerede depolanır?
Sorduğuna sevindim. İşte bu noktada barındırma devreye girer.
Depomu nerede barındırabilirim?
Depolarımızı nerede barındıracağımıza karar verirken birkaç seçeneğimiz var. Örneğin, bunları yerel bir sunucuda, Bitbucket'te veya GitHub'da barındırabiliriz. Bitbucket ve GitHub web tabanlı barındırma çözümleridir. Bunlara her yerden erişebiliriz.
İçlerinden birini kullandın mı?
Geçmişte GitHub kullandım. Komut satırından veya çevrimiçi portaldan günlükleri ve sürüm denetimi özelliklerini değiştirmek için kolay erişim gibi geliştiriciler için önemli özelliklere sahiptir.
Git nasıl çalışır?
Git ile çalışmak Nasıl yaparım??
Mara: Daha önce de belirttiğim gibi dağıtılmış sistemlerde geliştiriciler, deponun kendi kopyasına sahip oldukları için diğer geliştiricilerin çalışmalarını etkilemeden ihtiyaç duydukları herhangi bir dosyaya erişebilir. Kopya, deponun yerel kopyasıdır.
Bir özellik veya hata düzeltmesi üzerinde çalışırken, genellikle en iyi çözümü bulana kadar farklı yaklaşımlar denemek isteriz. Ancak, ana kod tabanı kopyanızda kod denemek iyi bir fikir değildir, çünkü ilk birkaç denemeyi sürdürmek istemeyebilirsiniz.
Daha iyi bir seçenek sunmak için Git'in dallanma adlı bir özelliği vardır. Burada istediğiniz kadar kopya bulundurabilir ve yalnızca saklamak istediğiniz kopyayı birleştirebilirsiniz. Bu, ana dalı kararlı tutar.
Şimdiye kadarki kavramları alıyorum. Kodumu iade Nasıl yaparım??
Yerel değişikliklerim ana kod tabanına nasıl ulaşacak?
Mara: Git'te varsayılan dal veya gövde genellikle olarak adlandırılır main.
Kodunuzun tüm geliştiriciler tarafından paylaşılan merkezi depodaki dalda main birleştirilmeye hazır olduğunu düşünüyorsanız, çekme isteği olarak adlandırılan bir şey oluşturursunuz. Çekme isteği oluşturduğunuzda, diğer geliştiricilere gözden geçirmeye hazır bir kodunuz olduğunu ve dalda main birleştirilmesini istediğinizi söylemiş olursunuz. Çekme isteğiniz onaylanıp birleştirildiğinde, merkezi kod tabanının bir parçası olur.
Dallanma iş akışı nasıl görünür?
1. Adım: Yeni bir özellik veya hata düzeltmesi üzerinde çalışmaya başladığınızda, yapmak istediğiniz ilk şey en son kararlı kod tabanıyla başladığınızı güvence altına almaktır. Bunu yapmak için, dalınızın yerel kopyasını sunucunun main kopyasıyla eşitleyebilirsiniz. Bu, son eşitlemenizden bu yana sunucudaki dala gönderilen main diğer tüm geliştirici değişikliklerini yerel kopyanıza çeker.
2. Adım: Yalnızca kod kopyanız üzerinde çalıştığınızdan emin olmak için, yalnızca bu özellik veya hata düzeltmesi için yeni bir dal oluşturursunuz. Tahmin edebileceğiniz gibi, yaptığınız tüm işlemler için birçok dalın olması anımsanması zor olabilir, bu nedenle iyi bir adlandırma kuralı kullanmak kritik önem taşır.
Bir dosyada değişiklik yapmadan önce, yeni bir dalı kullanıma alırsınız, böylece bu daldaki dosyalar üzerinde çalıştığınızı ve farklı bir daldan çalışmadığınızı bilirsiniz. İstediğiniz zaman bu dalı kullanıma alarak dallar arasında geçiş yapabilirsiniz.
3. Adım: Bu değişiklikler yalnızca dalınızda olduğundan artık istediğiniz değişiklikleri yapabilirsiniz. Çalışırken, hiçbir çalışmayı kaybetmediğinizden emin olmak ve önceki sürümlerde yaptığınız değişiklikleri geri almak için bir yol sağlamak için değişikliklerinizi dalınıza işleyebilirsiniz. Değişiklikleri işlemeden önce, Git'in hangilerini işlemeye hazır olduğunuzu bilmesi için dosyalarınızı hazırlamanız gerekir.
4. Adım: Sonraki adım , yerel dalınızı uzak depoya (GitHub gibi) göndererek veya karşıya yükleyerek başkalarının ne üzerinde çalıştığınızı görebilmesini sağlamaktır. Endişelenmeyin, bu işlem değişikliklerinizi henüz birleştirmez. İşinizi istediğiniz sıklıkta artırabilirsiniz. Aslında bu, çalışmanızı yedeklemek veya birden çok bilgisayardan çalışmanıza izin vermek için iyi bir yoldur.
5. Adım: Bu adım yaygın bir adımdır ancak gerekli değildir. Kodunuzun istediğiniz gibi çalıştığından memnun olduğunuzda, uzak dalı yerel main dalınıza geri çekebilir veya birleştirebilirsiniz.main Yerel main dalınızın henüz sahip olmadığı değişiklikler orada gerçekleşmiştir. Uzak main dalı kendi dalınızla eşitledikten sonra yerel main dalınızı çalışma dalınızla birleştirin ve derlemenizi yeniden test edin.
Bu işlem, özelliğinizin en son kodla çalışmasını sağlamaya yardımcı olur. Ayrıca, çekme isteğinizi gönderdiğinizde çalışmanızın sorunsuz bir şekilde tümleştirilmesine de yardımcı olur.
6. Adım: Yerel kodunuzun artık işlenmesi ve barındırılan depoya gönderilmesi gerekiyor. Bu, 3. ve 4. adımlarla aynıdır.
7. Adım: Son olarak uzak main dalda yaptığınız değişiklikleri önermeye hazırsınız. Bunu yapmak için bir çekme isteği başlatırsınız. Azure Pipelines veya başka bir CI/CD sisteminde yapılandırıldığında, bu adım derleme işlemini tetikler ve değişikliklerinizin işlem hattında ilerlemesini izleyebilirsiniz. Derleme başarılı olduktan ve diğerleri çekme isteğinizi onayladıktan sonra kodunuz uzak main dalda birleştirilebilir. (Değişiklikleri birleştirmek hala bir insana kalmış.)
Tüm bunlar karmaşık ve öğrenmesi zor görünüyor.
Mara: Git çok güçlü olduğu için göz korkutucu görünebilir, ancak akışın asılmasından sonra doğal hissetmeye başlar.
Her gün yalnızca birkaç komut kullanacaksınız. Özet aşağıdadır:
| Kategori | Bu görevi gerçekleştirmek için | Bu komutu kullan |
|---|---|---|
| Depo yönetimi | Git deposu oluşturma | git init |
| Uzak depo indirme | git clone |
|
| Şube | Dal oluşturma | git checkout |
| Değişiklikleri hazırlama ve işleme | Hangi dosyaların değiştirildiğini görün | git status |
| İşlemek için dosyaları hazırlama | git add |
|
| Dalınıza dosya işleme | git commit |
|
| Uzaktan eşitleme | Uzak bir depodan dal indirme | git pull |
| Uzak depoya dal yükleme | git push |
Bu harika bir başlangıç noktası gibi geliyor. Bunu kesinlikle halledebilirim. İhtiyacım olduğu için daha gelişmiş komutlar öğrenebiliyorum.