Git dallanma stratejisi nasıl seçilir: Git Flow, GitHub Flow ve ölçütler

Dallanma stratejisi neden gerekir?

Git'te dal açmak çok ucuzdur; zorluk dal açmakta değil, dalların nasıl bir düzenle yaşayıp birleşeceğine karar vermektedir. Strateji olmadığında herkes kendi alışkanlığıyla dal açar: kimi her işi doğrudan ana dala iter, kimi haftalarca ayrı bir dalda çalışır. Sonuç, çatışan değişiklikler, kimin neyi yayımladığının belirsizliği ve güvenilmeyen bir ana daldır.

Dallanma stratejisi, ekibin ortak sözleşmesidir: hangi dal ne için kullanılır, kodun ana dala girmesi için hangi adımlar gerekir, yayın nasıl çıkar, acil hata nasıl düzeltilir? İyi seçilmiş bir strateji bu soruları herkes için aynı yanıtlar. Önemli olan en gelişmiş modeli seçmek değil, ekibin yayın ritmine ve riskine uyan en sade modeli seçmektir.

Temel yapı taşları: uzun ömürlü dallar ve konu dalları

Git kitabı temel dal kullanımlarını anlatır. Uzun ömürlü dallarda birden çok dal geliştirme döngüsünün farklı aşamaları için açık kalır ve düzenli olarak birbirine birleştirilir. Kitabın örneğinde ana dal yalnız kararlı kodu içerir, paralel bir geliştirme dalı kararlılığı sınamak için kullanılır ve kararlı hale gelince ana dala birleştirilir. Dallar kararlılık düzeylerini temsil eder.

Konu dalı (topic branch) ise tek bir özellik ya da ilişkili iş için açılan kısa ömürlü daldır. Git'te dal oluşturmak, üzerinde çalışmak, birleştirmek ve silmek gün içinde birkaç kez yapılabilecek ucuz işlemlerdir. Konu dalları işi konuya göre ayırır, incelemeyi kolaylaştırır ve hazır olanın sırasından bağımsız birleştirilmesine izin verir.

Git Flow ve GitHub Flow, bu yapı taşlarını farklı oranlarda birleştirir: Git Flow uzun ömürlü dallara ağırlık verir, GitHub Flow ise neredeyse yalnızca kısa ömürlü konu dallarına dayanır.

Git Flow nasıl çalışır?

Git Flow, Vincent Driessen'in yayımladığı bir dallanma modelidir. Dal türleri şöyle tanımlanır: • Ana dal: her zaman üretime hazır kodu yansıtır; ana dala birleşen her işlem yeni bir yayın sayılır ve etiketlenir. • Geliştirme dalı: bir sonraki yayın için tamamlanmış son değişiklikleri toplayan entegrasyon dalıdır. • Özellik dalları: geliştirme dalından açılır, iş bitince geliştirme dalına geri birleştirilir. • Yayın dalları: geliştirme dalından açılır; son kontroller, küçük hata düzeltmeleri ve sürüm bilgisi için kullanılır, hem ana dala hem geliştirme dalına birleşir. • Acil düzeltme dalları: ana daldan açılır, üretimdeki acil hatayı düzeltir, hem ana dala hem geliştirme dalına döner.

Bu model, açıkça sürümlenen yazılımlarda ve aynı anda birden çok sürümü desteklemesi gereken ekiplerde anlamlıdır: örneğin müşteriye kurulumla verilen ürünler, mobil uygulama mağaza sürümleri ya da eski sürüme yama gerektiren kütüphaneler. Maliyeti, dal sayısı ve birleştirme yüküdür.

GitHub Flow nasıl çalışır?

GitHub'ın belgelerinde tanımlanan GitHub Flow, hafif ve dal tabanlı bir iş akışıdır. Adımlar şöyledir: kısa ve açıklayıcı adlı bir dal açılır, değişiklikler yapılıp gönderilir (her kayıt tek, tamamlanmış bir değişikliği içermelidir), geri bildirim için bir çekme isteği (pull request) açılır, inceleme yorumlarına yanıt verilir, onaydan sonra çekme isteği birleştirilir ve dal silinir. Dal koruma kuralları ve birleştirme çatışmaları birleştirmeyi engelleyebilir. Belgeler her ilgisiz değişiklik kümesi için ayrı dal önerir; böylece incelemeler odaklı kalır ve geciken bir değişiklik diğerlerini bekletmez.

Bu akışın sade olması, ana dalın her zaman dağıtılabilir olduğu varsayımına dayanır. Kodu ana dala almadan önce otomatik testlerin çalışması ve incelemenin yapılması, kararlılığı korur. Sürekli yayın yapan web ürünleri, dahili araçlar, hatta dokümantasyon ve politika depoları için doğal bir tercihtir.

Karar ölçütleri: hangi ekip hangisini seçmeli?

Seçimi tartışırken şu sorular işe yarar: • Yayın ritmi nedir? Sürekli yayın yapan ekip için kısa ömürlü dallar yeterlidir; planlı sürüm çıkışı yapan ekip yayın dalına ihtiyaç duyabilir. • Aynı anda kaç sürüm desteklenir? Birden çok canlı sürüm varsa, her sürüm için bakım dalı gerekir; Git Flow'un yapısı bunu doğal karşılar. • Test otomasyonu ne düzeyde? Güvenilir otomatik testler olmadan GitHub Flow'un 'ana dal her zaman dağıtılabilir' ilkesi korunamaz. • Ekip ne kadar büyük ve dağınık? Çok sayıda ekip aynı koda dokunuyorsa birleştirme disiplini ve koruma kuralları daha önemli hale gelir. • Gözden geçirme kültürü var mı? Çekme isteği olmadan sade model hızla kontrolsüz hale gelir.

Git Flow'un yazarı da modelin yıllar önce yazıldığını, sürekli teslim edilen web uygulamaları için GitHub Flow gibi daha basit bir akışın önerilebileceğini, buna karşılık açıkça sürümlenen yazılımlar ve birden çok sürümü destekleyen ekipler için modelin uygun olduğunu belirtir. 'Her derde deva' bir model yoktur; ekibin bağlamı belirleyicidir.

Örnek senaryo: küçük ürün ekibi

Kurgusal bir örnek olarak, bir çevrim içi sipariş uygulaması geliştiren küçük bir ekibi düşünelim. Uygulama günde birkaç kez yayımlanıyor, tek bir canlı sürüm var ve otomatik testler her çekme isteğinde çalışıyor. Bu ekip için GitHub Flow uygundur: her iş kısa bir dalda geliştirilir, çekme isteği açılır, testler geçer ve bir kişi inceleme yapar, sonra ana dala birleşir ve yayına alınır. Yayın dalı ve ayrı geliştirme dalı yalnız süreci ağırlaştırırdı.

Aynı ekip bir gün müşterinin kendi sunucusuna kurduğu bir kurumsal sürüm de çıkarmaya başlarsa tablo değişir. Müşteriler farklı sürümlerde kalacak, eski sürümlere hata düzeltmesi gerekecektir. Bu noktada sürüm başına bakım dalları ve daha yapılandırılmış bir yayın süreci gündeme gelir. Strateji değişmez bir kural değil, ürünün durumuna göre gözden geçirilen bir karardır.

Sık yapılan hatalar

Dallanma stratejilerinde sık görülen hatalar şunlardır: • Özellik dallarını haftalarca açık tutmak. Ana daldan uzaklaştıkça birleştirme çatışması büyür; dalları küçük tutun ve sık birleştirin. • Korumasız ana dal. Doğrudan ana dala gönderimi engelleyen, inceleme ve test gerektiren kurallar olmadan strateji kağıt üzerinde kalır. • Modeli körü körüne kopyalamak. Git Flow'u, tek canlı sürümü olan sürekli yayın yapan bir web ürününe uygulamak gereksiz yük getirir. • Dal adlandırma kuralı koymamak; hangi dalın ne işe yaradığı anlaşılmaz. • Birleştirme biçimini düşünmemek: birleştirme kaydı mı, sıkıştırma mı, yeniden temellendirme mi? Ekip tek bir yaklaşımda anlaşmalı, geçmişin okunabilir kalmasını gözetmelidir. • Yayın etiketlerini tutmamak; üretimde hangi kodun çalıştığı bulunamaz. • Acil düzeltme sürecini tanımlamamak; kriz anında herkes farklı yol izler.

Stratejiyi kısa bir sayfada yazılı hale getirmek, bu hataların çoğunu önler.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Sürüm Kontrolü İş Akışları (Git Flow, GitHub Flow) programı modül başlıklarına göre dallanma modellerinin karşılaştırmasını, birleştirme, geçmiş ve sürümlemeyi, yönetişim ve süreç tanımını kapsar. Bu içerik, yukarıdaki karar ölçütlerini kendi ekibinizde süreç haline getirmeye yöneliktir.