Trunk-Based Development feature branch'i tamamen yasaklar mı?

Hayır, tamamen yasaklamaz. Ancak feature branch'lerin ömrünün 1-2 günü geçmemesi beklenir. Daha uzun süren geliştirmelerde kod main'e feature flag arkasında kapalı olarak merge edilir; özellik tamamlandığında flag açılarak devreye alınır. Amaç, uzun ömürlü branch'lerin yarattığı entegrasyon acısını ortadan kaldırmaktır.

GitFlow neden eleştiriliyor?

Asıl eleştiri, modelin tasarlandığı 2010 yılındaki release tempolarına göre fazla katı kalmasıdır. Sürekli teslimat yapan SaaS ekiplerinde develop ve main arasındaki ikilik gereksiz bir overhead yaratır. Vincent Driessen kendi yazısına 2020'de bir not ekleyerek modelin sürümlü yazılımlar için tasarlandığını, sürekli teslimat ürünlerinde uygun olmayabileceğini belirtti.

Küçük bir ekip için en uygun strateji hangisi?

2-5 kişilik bir SaaS ekibi için GitHub Flow çoğu zaman en iyi seçimdir. Tek bir main dalı, kısa ömürlü feature branch'ler ve pull request tabanlı code review ile yönetilir. Karmaşık branch hiyerarşileri küçük ekibin enerjisini gereksiz yere tüketir; sade akış hız ve şeffaflık sağlar.

Feature flag kullanmadan Trunk-Based çalışılabilir mi?

Teknik olarak mümkün ama pratik değildir. Feature flag olmadan yarım kalan özelliklerin main'e merge edilmesi prod'a yarım iş çıkma riski yaratır. TBD'nin ölçeklenmesi için olgun bir feature flag altyapısı kritik bir gerekliliktir; LaunchDarkly, Unleash veya kendi yapılmış basit bir çözüm bu rolü üstlenebilir.

Birden fazla sürümü desteklemek zorundayım, hangi modeli seçmeliyim?

Müşterilerin farklı sürümlerini paralel desteklediğiniz kurumsal ürünlerde GitFlow hâlâ en güvenli seçimdir. Release branch'ler sayesinde geçmiş sürümlere hotfix göndermek, yeni sürüm geliştirirken eski sürümün stabilitesini korumak kolaylaşır. SaaS ürünlerinde ise tek prod sürümü olduğundan bu modele gerek kalmaz.

GitHub Flow ile GitLab Flow arasındaki fark nedir?

GitHub Flow yalnızca main ve kısa ömürlü feature branch'ler kullanır; merge sonrası deploy yapılır. GitLab Flow buna staging, pre-production, production gibi environment branch'ler ekler. Kod main'den bu ortam dallarına sıralı ilerler. Çoklu ortamda kontrollü dağıtım gereken ekipler için GitHub Flow'a göre daha yapılandırılmış bir alternatiftir.

Mevcut GitFlow'dan Trunk-Based'e nasıl geçilir?

Geçiş bir günde yapılmaz. Önce CI pipeline'ın hızlı ve güvenilir olduğundan emin olun, otomatik test kapsamasını ölçün ve feature flag altyapısı kurun. Sonra pilot bir servis veya takım üzerinde modeli deneyin. Code review SLA'sı net olmalı; küçük PR alışkanlığı tüm ekibe yayılmalı. Tipik olarak 2-3 ay süren kademeli bir kültür değişimidir.

Hangi strateji merge çatışmalarını en aza indirir?

Trunk-Based Development ve GitHub Flow merge çatışmalarını en aza indiren modellerdir, çünkü branch'ler kısa ömürlüdür ve sürekli entegrasyon yapılır. Uzun ömürlü branch'lerin biriktiği GitFlow benzeri modellerde release ve develop arasındaki büyük merge'ler çatışma riskini ciddi biçimde artırır. Çatışma azaltmanın kuralı basittir: branch ne kadar kısa yaşarsa, çatışma o kadar küçük olur.

GIT BRANCHING STRATEJİLERİ

Git turuncu logosunun parlak 3D rendering hali ile dallanma stratejilerinin marka kimliğindeki temsili

Aynı projede iki ekip aynı anda farklı kararlar veriyor: biri her gün main dalına merge ediyor, diğeri haftalarca süren feature branch'lerle çalışıyor. Hangisi doğru? Cevap ekibe, ürüne ve release temposuna göre değişiyor. Trunk-Based Development hızlı entegrasyon vaat ederken GitFlow sürümlü ürünlerde disiplin getiriyor, GitHub Flow ise sürekli teslimat yapan ekiplere sadelik sunuyor. Yanlış strateji; çatışmaları büyütür, dağıtımı yavaşlatır, ekibin moralini bozar. Doğru strateji ise neredeyse görünmez biçimde geliştirme akışını rahatlatır.

Dallanma Stratejisi Neden Önemli

Git, esnek bir araç olduğu için onlarca farklı dallanma modeli mümkündür. Ancak ekip içinde ortak bir kural setine bağlı kalmadan çalışmak; merge çatışmaları, kayıp commit'ler, bozuk release süreçleri olarak geri döner. Dallanma stratejisi aslında bir ekip anlaşmasıdır: kim ne zaman, nereye yazar; kod hangi aşamada doğrulanır; sürümler nasıl kesilir.

Strateji seçerken üç temel parametreye bakılır:

Ekip büyüklüğü: 3 kişilik ekiple 50 kişilik ekibin çatışma riski aynı değildir
Release temposu: Günlük deploy mu, üç ayda bir sürüm mü çıkarılıyor
Ürün tipi: SaaS uygulaması mı, çoklu sürüm desteklenen kurumsal yazılım mı
Test altyapısı: Otomatik test kapsaması düşükse uzun ömürlü branch'ler kaçınılmaz olabilir
Müşteri çeşitliliği: Tek bir prod ortamı mı, yoksa farklı sürümler kullanan müşteriler mi var

Trunk-Based Development

Trunk-Based Development (TBD), tüm geliştiricilerin main (trunk) dalına günde en az bir kez kod entegre ettiği modeldir. Feature branch'ler ya hiç açılmaz ya da çok kısa ömürlüdür; tipik olarak 1-2 gün içinde kapanır. Yarım kalan özellikler feature flag arkasına gizlenir.

Bu yaklaşımın gücü, entegrasyon acısını sıfıra yakın tutmasıdır. Geliştiriciler birbirinin değişikliklerinden saatler içinde haberdar olur, büyük merge dramları yaşanmaz. Google, Facebook ve Netflix gibi şirketlerin tercih ettiği modelin temelinde bu vardır.

Ancak TBD'nin işlemesi için bazı önkoşullar gereklidir:

Güçlü otomatik test paketi (unit, integration, end-to-end)
Feature flag altyapısı
Hızlı ve güvenilir CI pipeline
Code review kültürünün hızlı işlemesi
Kıdemli geliştirici oranı yüksek bir ekip

Trunk-Based GitFlow ve GitHub Flow dallanma stratejilerinin yan yana branch yapısı karşılaştırması

GitFlow Modeli

2010'da Vincent Driessen tarafından yayımlanan GitFlow, uzun yıllar boyunca standart dallanma modeli olarak görüldü. Modelde main (production), develop (entegrasyon), feature/*, release/* ve hotfix/* olmak üzere birden çok branch ailesi bulunur. Modelin tüm akış diyagramları ve örnek senaryoları için orijinal kaynak makaleyi inceleyebilirsiniz.

Akış şu şekilde işler:

Yeni özellik develop'tan bir feature branch açılarak geliştirilir
Tamamlanan feature, develop'a merge edilir
Sürüm hazırlandığında develop'tan release branch çıkarılır
Release branch'te yalnızca hata düzeltmeleri yapılır
Release tamamlanınca main'e ve develop'a merge edilir, tag atılır
Acil prod hatası için main'den hotfix branch açılır, çözüldükten sonra main ve develop'a döner

GitFlow'un asıl değeri, paralel sürümlerin desteklendiği ve release süreci formal olan ürünlerde ortaya çıkar. Örneğin müşterilerin v2.4 kullandığı, ekibin v3.0 geliştirdiği, prod'da v2.3 hotfix'i alınması gereken senaryolarda model olgun davranır. Buna karşılık SaaS ürünlerinde GitFlow çoğunlukla gereksiz karmaşıklık getirir; tek bir prod sürümü olan ekiplerde develop ve main arasındaki ikilik anlamsız bir overhead'e dönüşür. Git'in temel komutlarını yeniden hatırlamak isterseniz Git eğitimi içeriğinden yararlanabilirsiniz.

GitHub Flow ve GitLab Flow

GitHub Flow, GitFlow'un sadeleştirilmiş kuzenidir. Tek bir uzun ömürlü dal vardır: main. Her yeni iş için main'den kısa ömürlü bir branch açılır, geliştirme tamamlandığında pull request ile main'e merge edilir, ardından deploy edilir. Develop, release, hotfix gibi ek katmanlar yoktur.

Bu model özellikle sürekli teslimat (continuous deployment) yapan ekiplerde işe yarar. Her merge potansiyel bir prod deploy'udur; bu yüzden CI/CD pipeline'ının olgun olması beklenir.

GitLab Flow ise GitHub Flow'a "environment branch" kavramı ekler. main dışında staging, pre-production, production gibi ortam dalları tutulur ve kod bu dallar arasında sırayla ilerler. Çoklu ortamda ilerleyen ürünlerde GitHub Flow'un sadeliğini koruyup ortam yönetimi sağlar.

Ekip Büyüklüğü ve Strateji Eşleşmesi

Hangi modelin hangi ekibe uyduğunu netleştirmek için pratik bir eşleşme tablosu kuralım:

2-5 kişilik küçük ekip, SaaS: GitHub Flow ideal. Kısa branch, hızlı merge, sürekli deploy
5-15 kişilik orta ekip, güçlü test: Trunk-Based Development verim sağlar
15-50 kişilik ekip, modüler ürün: GitHub Flow + monorepo veya TBD + feature flag
Çoklu sürüm destekleyen kurumsal ürün: GitFlow hâlâ en güvenli seçim
Açık kaynak proje, çok sayıda dışarıdan katkıcı: Fork tabanlı + GitHub Flow benzeri
Düşük test kapsaması olan legacy proje: GitFlow'un release branch disiplini risk azaltır

Release Temposu ile Uyum

Strateji seçiminde belki de en belirleyici parametre ne sıklıkta sürüm çıkarıldığıdır. Günde birden çok deploy yapan bir SaaS ekibine GitFlow zorla giydirilirse develop ve main arasındaki sürekli senkronizasyon ek bir maliyet yaratır. Tersine, üç ayda bir sürüm çıkaran bir ürün ekibine TBD önerildiğinde feature flag yönetimi başlı başına bir teknik borç haline gelir.

Genel pratik kural şudur: release sıklığı arttıkça branch sayısı azalmalı, release sıklığı azaldıkça branch'lerin görev tanımı netleşmelidir.

Geçişte Dikkat Edilecekler

Mevcut bir stratejiden başkasına geçiş, çoğu zaman teknik değil kültürel bir değişikliktir. GitFlow'dan TBD'ye geçen bir ekip; küçük PR alışkanlığı, feature flag kütüphanesi seçimi, code review SLA'sı gibi pek çok konuda yeniden anlaşma yapmak zorundadır.

Geçiş sürecini sağlıklı yürütmek için:

Önce CI/CD pipeline'ını hedef stratejiye uygun hale getirin
Yeni branch isimlendirme kurallarını yazılı hale getirin
Bir pilot takım veya pilot servis üzerinde deneyin
Eski uzun ömürlü branch'leri kapatın, kalıntı bırakmayın
Code review sürelerini ölçmeye başlayın; uzun bekleyen PR strateji ne olursa olsun sorun yaratır

Hangi stratejiyi seçerseniz seçin, asıl mesele ekibin bu modeli istisnasız uygulayabilmesidir. En sade GitHub Flow bile yarım kalan PR'lar ve unutulan branch'lerle çürüyebilir; en katı GitFlow bile disiplinli bir ekibin elinde akıcı bir release motoru olabilir. Doğru cevap "GitFlow mu, Trunk-Based mi" değil; "ekibim hangisini sürdürebilir, ürünüm hangisini hak ediyor" sorusunun cevabıdır.