GİT BRANCHİNG STRATEJİLERİ: TRUNK-BASED MI GİTFLOW MU?

Bir ekibin teslim hızını belirleyen şey çoğu zaman “ne kadar kod yazdığı” değil, o kodun hangi dal stratejisi ile birleştiğidir. Aynı ürün üzerinde onlarca geliştirici çalışırken branch yapısı yanlış kurgulanmışsa, küçük bir değişiklik bile günlerce sürüp “merge savaşına” dönüşebilir.

Bu yazıda Git branching stratejileri içinde en yaygın iki yaklaşımı, Trunk-Based Development ve GitFlowu, pratik senaryolar üzerinden karşılaştıracağız. Hangi ekipte hangisi daha iyi çalışır, riskleri nasıl yönetilir, CI/CD ile nasıl uyumlanır gibi sorulara net ölçütlerle yaklaşacağız.

Ayrıca karar vermeyi kolaylaştırmak için somut kriterler, örnek git komutları ve önerilen branch isimlendirmeleri de paylaşacağım. Daha derin pratikler için Git eğitimi sayfasına da göz atabilirsiniz.

Primary yaklaşım: Git branching stratejileri neyi optimize eder?

Branching modeli seçimi temelde üç şeyi optimize etmeye çalışır: entegrasyon sıklığı, yayına çıkış güveni ve eşzamanlı çalışma verimi. Bir model, hızlı entegrasyon adına kısa ömürlü dalları teşvik ederken; diğeri sürüm disiplinini artırmak için daha fazla kalıcı dal önerebilir.

Bu kararın doğru olması için “hangi model popüler” sorusundan çok, ürününüzün teslim biçimini anlamak gerekir. Örneğin günde birkaç kez prod’a çıkıyorsanız, uzun yaşayan feature branch’ler gecikme ve çakışma riskini yükseltir. Ancak regülasyonun yoğun olduğu bir ortamda sürüm kapıları çok katıysa, ayrı release hatları yönetilebilirlik sağlar.

Başlıca terimler: trunk, feature, release, hotfix

Trunk çoğu ekipte main veya master gibi tek doğruluk kaynağı olan daldır. Feature branch bir işi izole eder; release branch belirli bir sürümü sabitler; hotfix ise acil üretim düzeltmeleri için tasarlanır.

Hata maliyeti ve entegrasyon sıklığı ilişkisi

Bir değişiklik trunk’a ne kadar geç birleşirse, çevresinde biriken diğer değişikliklerle birlikte “sürpriz” üretme olasılığı o kadar artar. Bu nedenle modern ekipler, daha sık entegrasyon ve daha erken geri bildirim için CI testlerini ve otomatik kontrolleri kritik görür.

Trunk-Based Development: Kısa ömürlü dallarla hızlı entegrasyon

Trunk-Based Development yaklaşımında hedef, trunk üzerinde sürekli entegre olmak ve dalları çok kısa ömürlü tutmaktır. Bu model, CI/CD pratikleriyle güçlü biçimde örtüşür: küçük değişiklikler, hızlı test, hızlı geri dönüş.

Trunk-based’in kalbi “küçük dilimler”dir. Büyük bir özelliği haftalarca bir dalda bekletmek yerine, mümkünse birkaç saat–bir gün içinde trunk’a girecek şekilde parçalamak tercih edilir. Riskli kısımlar ise branch yerine feature flag’lerle güvenli biçimde saklanabilir.

Trunk-based iş akışı örneği (komutlar)

git checkout main
git pull --rebase

# Kısa ömürlü dal: 1-2 gün içinde kapanacak şekilde
git checkout -b feat/login-rate-limit

# Değişiklikleri ekle
git add .
git commit -m "Add rate limiting for login endpoint"

# Güncel main ile sık sık rebase/merge
git fetch origin
git rebase origin/main

# PR aç ve hızlı geri bildirim al
git push -u origin feat/login-rate-limit

Bu akışta kritik nokta, PR’ın küçük ve incelenebilir olmasıdır. Kod inceleme daha hızlı biter, CI daha çabuk çalışır, birleştirme sonrası sorun çıkarsa geri almak daha kolaydır.

Feature flag ile risk yönetimi

Trunk-based ekiplerde sık görülen pratiklerden biri, tamamlanmamış davranışı feature flag arkasına almak ve trunk’a erken taşımaktır. Böylece branch’te bekleyen büyük değişiklikler yerine, trunk üzerinde “kapalı” özellikler birikir; aktivasyon kontrollü yapılır.

GitFlow: Sürüm hatlarıyla disiplinli yayın yönetimi

GitFlow modeli klasik olarak uzun ömürlü iki ana dal (main ve develop) ve bunların etrafında dönen feature/release/hotfix dalları önerir. Özellikle planlı sürümlerle ilerleyen, yayın takvimi olan ve kalite kapıları belirgin ekiplerde hâlâ kullanılabilir bir düzen sağlar.

GitFlow’da release branch kritik bir rol üstlenir: sürüm stabilizasyonu burada yapılır, son düzeltmeler ve versiyon metadata işleri bu dalda toplanır. Üretim dalı ise daha “temiz” kalır ve her zaman yayınlanabilir durumda tutulmaya çalışılır.

GitFlow dal isimlendirme ve akış şablonu

• feature/ ile başlayan dallar: yeni özellik çalışmaları
• release/ ile başlayan dallar: sürüm sabitleme ve stabilizasyon
• hotfix/ ile başlayan dallar: üretimde acil düzeltmeler

GitFlow release/hotfix örneği (komutlar)

# Feature tamamlandıktan sonra develop'a birleşir (PR ile)
git checkout develop
git pull --rebase

# Yayın öncesi release dalı açılır
git checkout -b release/1.8.0
git push -u origin release/1.8.0

# Stabilizasyon commit'leri
git commit -am "Bump version to 1.8.0"
git commit -am "Fix minor validation edge case"

# Release, main'e ve develop'a geri birleşir (etiketleme dahil)
git checkout main
git merge --no-ff release/1.8.0
git tag -a v1.8.0 -m "Release 1.8.0"
git push --follow-tags

git checkout develop
git merge --no-ff release/1.8.0
git push

Bu yapı, “sürüm hazırlığı”nı üretim akışından ayırdığı için netlik sağlar. Ancak süreç uzadıkça release dalında biriken değişiklikler, trunk-based’e göre daha büyük entegrasyon riskleri doğurabilir.

Karşılaştırma: Trunk-Based mi GitFlow mu?

İki yaklaşımın da doğru bağlamda ciddi faydası var. Burada belirleyici olan, ekibin teslim sıklığı, test otomasyonu olgunluğu ve ürünün risk profili. Aşağıdaki başlıklar karar vermeyi pratikleştirir.

Yayın frekansı ve CI/CD olgunluğu

Günde sık yayın yapan ekiplerde trunk-based genellikle daha iyi sonuç verir; çünkü küçük PR’lar, hızlı testler ve otomatik dağıtım boru hatları ile uyumlu ilerler. Yayınların haftalık/aylık olduğu ve “release trenleri” ile gidildiği ekiplerde GitFlow’un release dalı disiplin sağlayabilir.

Merge conflict azaltma ve dal ömrü

Merge conflict riski, dalın ne kadar uzun yaşadığıyla doğrudan ilişkilidir. Trunk-based, dal ömrünü kısalttığı için çatışmaları azaltır. GitFlow’da ise conflict riskini düşürmek için feature dallarını kısa tutmak, develop ile sık senkronize olmak ve release stabilizasyonunu mümkün olduğunca hızlı tamamlamak gerekir.

Hibrit çözümler: “Sade GitFlow” ve “Trunk + Release branch”

Gerçek dünyada ekipler çoğu zaman iki uç arasında hibrit bir model kurar. Örneğin trunk-based yaklaşımını benimseyip, sadece büyük sürümlerde kısa süreli bir release branch açmak pratik bir denge sunabilir. Böylece trunk üzerinde hız korunurken, sürüm stabilizasyonu için kısa bir alan yaratılır.

Benzer şekilde GitFlow kullanan ekipler de “develop” dalını sürekli canlı tutmak yerine, develop’ı trunk gibi kullanıp, release/hotfix dallarını daha minimal hale getirerek sadeleştirebilir. Burada amaç, modelin ritüellerini değil, ekibin hedeflerini optimize etmektir.

Trunk + kısa süreli release dalı ne zaman işe yarar?

Üretime sık çıkıp yine de belirli müşterilere sürüm paketleri hazırlıyorsanız, trunk-based + kısa release dalı iyi çalışır. Release dalı sadece stabilizasyon için açılır; uzun süren geliştirme burada birikmez. Bu yaklaşım, sürümleme stratejisi ve dağıtım pratikleriyle birlikte düşünülmelidir.

Uygulama rehberi: Hangi kriterlerle seçim yapılır?

Son kararı verirken tartışmayı “model ismi” üzerinden değil, ölçülebilir kriterler üzerinden yürütün. Aşağıdaki checklist, toplantılarda anlaşmayı kolaylaştırır.

Seçim checklist’i

1. Günlük/haftalık ortalama yayın sayısı kaç?
2. Test otomasyonu (unit/integration/e2e) kapsama ve güven seviyesi nedir?
3. Değişikliklerin geri alınması ne kadar kolay? (rollback stratejisi)
4. Ürün regülasyon/denetim gerektiriyor mu?
5. Çoklu takım aynı repoda mı çalışıyor, yoksa servisler ayrık mı?

Pratik ipuçları: Her iki modelde de başarıyı artıran alışkanlıklar

Hangi modeli seçerseniz seçin, bazı pratikler neredeyse evrensel biçimde başarı getirir. Özellikle PR kalitesi ve otomatik kontroller, branching modelinin “kağıt üzerindeki” güzelliğini sahaya taşır.

Küçük PR, net açıklama, güçlü kod inceleme

PR’ları küçük tutmak, incelemeyi hızlandırır ve hatayı erken yakalatır. PR açıklamasında “ne değişti” kadar “neden değişti”yi de belirtmek, ekip içi bağlam kaybını azaltır. Bu alışkanlık, pull request akışını daha verimli hale getirir.

CI kapıları ve trunk güvenliği

Trunk’ın her an dağıtılabilir kalması için CI kapıları kritik: lint, test, güvenlik taraması, kalite metrikleri gibi kontrollerin otomatik çalışması gerekir. Eğer bunlar zayıfsa trunk-based kaos yaratabilir; GitFlow ise sorunları geciktirerek gizleyebilir. Bu nedenle süreçten önce “otomasyon”u güçlendirmek çoğu ekipte en büyük kaldıraçtır.

Özetle, Trunk-Based hız ve sürekli entegrasyon için güçlü bir seçenekken, GitFlow planlı sürüm yönetiminde düzen sağlar. Ekip kültürü, test otomasyonu ve yayın ritmi doğru okunursa, iki yaklaşım da başarılı olabilir. Kritik olan; dal sayısını artırmak değil, entegrasyonu hızlandırıp riski görünür kılmaktır.