Dallanma Stratejisi: Trunk-Based mi, Git Flow mu?

Dallanma stratejisi tartışması, ekiplerde şaşırtıcı derecede uzun sürer ve genellikle yanlış eksende yapılır: "Git Flow mu, trunk-based mi?" Oysa sahadaki acının kaynağı seçilen model değil, dalların ne kadar yaşadığıdır. Üç hafta yaşayan bir dal, hangi modeli kullanırsanız kullanın birleştirme acısı üretir.

Üç yaygın model

Git Flow

Kalıcı main ve develop dalları, ayrıca özellik, yayın ve acil düzeltme dalları içerir. Sürümlü ürünlerde (masaüstü uygulamaları, aynı anda birden çok sürümü desteklenen kütüphaneler) hâlâ anlamlıdır.

Sürekli dağıtım yapan web ekiplerinde ise gereğinden karmaşıktır: develop ve main arasındaki fark yönetim yükü üretir, dallar uzar ve entegrasyon geç olur.

GitHub Flow

Tek kalıcı dal (main) ve kısa ömürlü özellik dalları. Her dal bir birleştirme isteğiyle incelenir, otomatik testlerden geçer ve birleştirildiğinde dağıtılır. Sürekli dağıtım yapan çoğu ekip için doğru dengedir.

Trunk-based development

Değişiklikler doğrudan ana dala veya çok kısa ömürlü (bir günü geçmeyen) dallara yazılır. Tamamlanmamış işler özellik bayraklarıyla kapalı tutulur. Yüksek olgunluk gerektirir: güçlü otomatik test, hızlı dağıtım hattı ve bayrak yönetimi disiplini.

Asıl değişken: dal ömrü

Model seçiminden çok daha belirleyici olan, bir dalın ne kadar yaşadığıdır. Uzun ömürlü dalın maliyetleri şunlardır: her gün büyüyen birleştirme çatışması riski, incelenmesi imkânsız hâle gelen dev bir fark, geç fark edilen mimari uyumsuzluk ve "bu kadar emek verdik, artık geri dönemeyiz" baskısı.

Buna karşılık dal ömrü bir-iki güne indiğinde bu sorunların neredeyse tamamı kendiliğinden kaybolur. Küçük değişiklikler daha iyi incelenir; incelemenin kalitesi doğrudan büyüklüğe bağlıdır — kod incelemesi yazımızda değindiğimiz gibi, 800 satırlık bir fark pratikte incelenmez, onaylanır.

Büyük işi küçük parçalara bölmek

"Bizim işimiz büyük, iki günde bitmez" itirazı haklıdır ama sonuç yanlıştır. Büyük iş, uzun dal gerektirmez; parçalanabilir. Üç teknik işe yarar:

• Özellik bayrağı: Kod ana dala girer ama kullanıcıya kapalıdır. Bu, en güçlü araçtır çünkü yayın kararını birleştirme kararından ayırır.
• Genişlet-daralt deseni: Şema ve arayüz değişikliklerinde önce yeni yapı eklenir, iki yapı bir süre birlikte yaşar, sonra eski kaldırılır. Aynı desen sıfır kesintili göç yazımızda ayrıntılandırılıyor.
• Önce altyapı, sonra davranış: Yeniden düzenlemeler ayrı ve küçük commit'ler hâlinde önden birleştirilir; asıl özellik geldiğinde fark küçülür. Bu adımları güvenle yapmak için editörün yeniden düzenleme araçları yazımıza bakın.

Özellik bayraklarının bedeli

Bayraklar bedava değildir: her bayrak bir dallanma, dolayısıyla test edilmesi gereken bir kombinasyon üretir. Unutulan bayraklar zamanla kod tabanını çözülmez hâle getirir.

Pratik kural, her bayrağa bir sahip ve bir son kullanma tarihi vermektir. Özellik tamamen açıldıktan sonra bayrağın kaldırılması, işin bitmemiş son adımıdır — atlanırsa teknik borç birikir.

Birleştirme yöntemi: squash mi, merge mi?

Bu ayrı ama bağlantılı bir karardır. Sıkıştırarak birleştirme (squash) ana dal geçmişini temiz tutar ve her özellik tek bir commit olur; ara adımların ayrıntısı kaybolur. Doğrudan birleştirme ise geçmişi korur ama gürültü üretir. Ekip için doğru seçimi tartışan rebase mi merge mi yazımız bu kararı ayrıntılandırıyor.

Hangi yöntem seçilirse seçilsin belirleyici olan tutarlılıktır: karışık kullanım, geçmişi okunmaz hâle getirir.

Ekibinize uygun olanı nasıl seçersiniz?

Üç soru genellikle cevabı verir. Ne sıklıkla dağıtım yapıyorsunuz — günde birkaç kez mi, ayda bir mi? Aynı anda kaç sürümü desteklemek zorundasınız? Otomatik test kapsamınız, ana dala doğrudan yazmaya güvenmenizi sağlıyor mu?

Günde birkaç kez dağıtım yapan, tek sürüm destekleyen ve testleri sağlam bir ekip için trunk-based en verimlisidir. Testleri zayıf bir ekip için ise aynı model risklidir — özellikle testler kırılgansa ana dala güvenmek mümkün olmaz; önce dağıtım hattı ve test kapsamı güçlendirilmelidir — CI/CD yazımız bu temeli kurmayı ele alıyor. Komutların resmî davranışı için Git dokümantasyonu başvurulacak kaynaktır.

Sonuç

Dallanma stratejisi tartışmasının doğru cevabı model adı değil, bir alışkanlıktır: dalları kısa tutmak. Git Flow sürümlü ürünlerde, GitHub Flow sürekli dağıtım yapan çoğu ekipte, trunk-based ise güçlü test altyapısı olan olgun ekiplerde en iyi sonucu verir; ancak üçünde de belirleyici olan dalın ömrüdür. Bu hafta ekibinizde küçük bir ölçüm yapın: açık dallarınızın yaşını listeleyin. Üç günden eski dalların sayısı, birleştirme acınızın da ölçüsüdür.