Git Flow mu Trunk-Based mi? Mobil Dallanma Rehberi

Bir mobil ekip yeni bir sprint başında hep aynı soruyla karşılaşır: özellik dalları haftalarca mı yaşasın, yoksa herkes doğrudan tek bir hatta mı commit atsın? Git flow trunk based development farkı, mobil ekipler için basit bir stil tercihi değil; mağaza incelemesi, sürüm treni ve hotfix baskısı yüzünden gerçek bir mimari karardır. Bu rehberde iki modelin tarihçesinden mobil'e özel karar çerçevesine kadar, kaynaklı ve uygulanabilir bir yol haritası bulacaksın.

💡 Pro Tip: Kararı "hangisi daha modern" diye değil, "sürümlerimiz kaç tanesi aynı anda vahşi doğada yaşıyor" diye sor — cevap seni doğrudan doğru modele götürür.

İçindekiler

• İki Modelin Tanımı ve Tarihçesi
• Mobil Ekipleri Farklı Kılan Şey
• Git Flow'un Mobil Projede Gerçek Maliyeti
• Trunk-Based'in Ön Koşulları
• Sürekli entegrasyon altyapısı
• Feature flag altyapısı
• Hafif kod inceleme kültürü
• Hibrit: Release Dalı + Trunk (Release Train)
• Sürüm Numaralandırma ve Dal Adlandırma
• Karar Çerçevesi
• Geçiş Planı: Git Flow'dan Trunk-Based'e 4 Hafta
• Hafta 1: CI'yi günlük çalışır hale getir
• Hafta 2: Dal sayısını 3'e indir
• Hafta 3: Feature flag altyapısını kur
• Hafta 4: İlk release train'i çalıştır
• Sık Hatalar
• SSS
• Git Flow ile trunk-based development arasındaki fark nedir?
• Mobil uygulama ekipleri için hangi dallanma stratejisi daha uygun?
• Trunk-based development için feature flag zorunlu mu?
• Release dalı ile hotfix dalı aynı şey mi?
• CI'ım henüz olgun değilse trunk-based'e geçmeli miyim?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

İki Modelin Tanımı ve Tarihçesi

Git flow, Vincent Driessen tarafından 2010'da tanımlandı. Modelin merkezinde iki sonsuz ömürlü dal var: master, her zaman üretime hazır durumu yansıtır; develop ise "bir sonraki sürüm için teslim edilen en son geliştirme değişikliklerinin durumunu yansıtan entegrasyon dalı"dır. Bunların üzerine feature/*, release/* ve hotfix/* dalları eklenir.

Driessen, 2020'de kendi modeline bir "reflection" notu ekledi ve şunu yazdı: "Eğer ekibiniz yazılımın sürekli teslimatını yapıyorsa, git-flow'u ekibinize zorla sığdırmaya çalışmak yerine (GitHub flow gibi) çok daha basit bir iş akışı benimsemenizi öneririm." Aynı notta sınırı da çizdi: "Eğer açıkça sürümlenen bir yazılım geliştiriyorsanız ya da yazılımınızın birden fazla sürümünü vahşi doğada desteklemeniz gerekiyorsa, git-flow hâlâ iyi bir uyum olabilir." Mobil uygulamalar tam olarak bu ikinci kategoriye girer: mağazada aynı anda birden fazla build sürümü kullanıcıların elinde olabilir ve her sürüm ayrı ayrı desteklenmesi gerekebilir.

Trunk-based development ise tam tersi bir felsefeyle çalışır: geliştiriciler "trunk" adı verilen tek bir dal üzerinde iş birliği yapar ve başka uzun ömürlü geliştirme dalları oluşturma baskısına direnir. Git dünyasında bu dal 2020'den beri çoğunlukla main olarak adlandırılıyor. Trunkbaseddevelopment.com'un kendi verdiği ölçek kanıtı çarpıcı: Google, 35.000 geliştirici ve QA otomasyoncusunun tek bir monorepo trunk'ında çalıştığı trunk-based development uyguluyor.

Google Cloud'un DORA (dora.dev) araştırma programı, trunk-based development'ı "geliştiricilerin trunk'a sık sık bireysel değişikliklerini birleştirdiği, dalların genellikle birkaç saatten fazla yaşamadığı" bir pratik olarak tanımlar ve üç somut kural verir: "Üç veya daha az aktif dalınız olsun. Dalları en az günde bir kez trunk'a birleştirin. Code freeze yapmayın ve entegrasyon fazlarınız olmasın." Bu kurallar 2016 ve 2017 State of DevOps raporlarına dayanıyor.

Mobil Ekipleri Farklı Kılan Şey

Web deploy'unda bir hata fark ettiğinde geri alman dakikalar sürer. Mobilde durum farklı: App Store ve Play Store dağıtımı, "anında geri alınamaz" bir yayın adımı içerir — inceleme kuyruğuna giren bir build, onaylanana kadar senin kontrolünde değildir. Bu yapısal fark, git-flow'un release ve hotfix dallarının neden mobilde hâlâ anlamlı olduğunu açıklar: trunkbaseddevelopment.com'un kendi ifadesiyle "trunk-based development ekiplerinin just-in-time bazda, örneğin yayından birkaç gün önce bir release dalı oluşturması yaygındır."

Bu release dalının kuralı da nettir; 1998'den Wingerd ve Seiwald'ın klasik whitepaper'ından alınan ilkeyle, release dalı "devam eden geliştirme çalışması almamalıdır." Yani release dalı dondurulur, sadece hedeflenmiş hata düzeltmeleri (cherry-pick ile) alır; yeni özellik geliştirmesi trunk'ta devam eder. Sürekli teslimat yapan (CD) ekipler ise release dalı hiç kullanmaz; bunun yerine "roll-forward" stratejisi seçerler — hata düzeltmesi trunk'a girer ve üretime yayın doğrudan trunk'tan yapılır. Mobilde saf roll-forward, mağaza incelemesi araya girdiği için üretime doğrudan uygulanamaz, ama prensip hâlâ geçerli: hotfix'in kaynağı trunk olmalı, unutulmuş bir eski dal değil.

Hotfix ihtiyacı iki modelde de karşılanabilir: git-flow'un kendi hotfix/* dalı ile, ya da trunk-based'in release dalına cherry-pick ile. Fark, günlük geliştirmenin nerede yaşadığıdır — git-flow'da develop'ta, trunk-based'de doğrudan main'de.

Git Flow'un Mobil Projede Gerçek Maliyeti

Driessen'in kendi 2020 notu, sürekli teslimat yapan ekipler için git-flow'un fazla ağır kaldığını söylüyor. Bunun tersi de doğru: uzun ömürlü develop ve feature/* dalları, büyük ve seyrek merge olaylarına yol açar. DORA'nın "code freeze ve entegrasyon fazı olmasın" kuralı, tam olarak bu senaryonun karşıtıdır — develop dalı haftalarca birikince, release öncesi bir "entegrasyon haftası" kaçınılmaz hale gelir.

DORA'nın "Common pitfalls" bölümünde işaret ettiği bir başka engel de code review kültürüyle ilgili: "Birçok organizasyon, değişikliklerin trunk'a birleştirilmeden önce birden fazla onay gerektiren ağır bir code review süreci uyguluyor." DORA aynı bölümde ekliyor: code review zahmetli olup saatler ya da günler sürdüğünde, geliştiriciler küçük batch'ler halinde çalışmaktan kaçınıyor. Uzun ömürlü dallar bu ağır review sürecini besler: PR ne kadar büyürse, incelemesi o kadar gecikir, gecikme dalın ömrünü daha da uzatır — kısır döngü.

1# Git flow'da tipik bir merge çatışması senaryosu
2git checkout develop
3git pull origin develop
4git merge feature/payment-v2
5# CONFLICT (content): Merge conflict in Sources/Payment/PaymentViewModel.swift
6# örneğin, haftalarca açık kalan bir feature dalı develop'taki onlarca commit'i yakalamaya çalışıyor

Trunk-Based'in Ön Koşulları

Trunk-based development "önce disiplin, sonra dal" mantığıyla çalışır. Üç ön koşul olmadan mobilde denemesi risklidir.

Sürekli entegrasyon altyapısı

DORA'nın Continuous Integration tanımı nettir: "Build sürecinizi günde en az bir kez başarıyla çalıştırmalısınız... Testleriniz de günde en az bir kez başarıyla çalışmalı." 2015 State of DevOps Report, geliştiricilerin işlerini en az günde bir kez trunk'a birleştirdiği ekiplerin daha iyi performans gösterdiğini ortaya koyuyor. Mobilde bu, her PR'da simulator/device testlerini çalıştıran bir CI hattı (örneğin Xcode Cloud, Bitrise ya da GitHub Actions + fastlane) anlamına gelir.

1# .github/workflows/pr-check.yml — trunk'a merge öncesi zorunlu kapı
2on:
3  pull_request:
4    branches: [main]
5jobs:
6  test:
7    runs-on: macos-15
8    steps:
9      - uses: actions/checkout@v4
10      - run: sudo xcode-select -s /Applications/Xcode_26.0.app
11      - run: xcodebuild test -scheme App -destination 'platform=iOS Simulator,name=iPhone 17'

Feature flag altyapısı

Martin Fowler bu tekniğe "Feature Toggles" adını vermişti; trunkbaseddevelopment.com ise sektörde daha yaygın kullanılan adıyla "Feature Flags" terimini tercih ediyor. Adı ne olursa olsun mantık aynı: yarım kalan özellik trunk'a erken girer ama kapalı kalır.

1// Basit bir feature flag: özellik trunk'ta ama kapatılabilir
2// AppConfig, uzaktan yapılandırma sağlayıcın (Firebase Remote Config, LaunchDarkly vb.) üzerine kurduğun kendi sarmalayıcın
3enum FeatureFlag {
4    static var newOnboardingFlow: Bool {
5        AppConfig.shared.bool(forKey: "new_onboarding_flow")
6    }
7}
8 
9func presentOnboarding() {
10    if FeatureFlag.newOnboardingFlow {
11        presentNewOnboarding()
12    } else {
13        presentLegacyOnboarding()
14    }
15}

Böylece yarım kalan bir onboarding akışı bile trunk'a günlük olarak girebilir; mağazaya giden build'de flag kapalıysa kullanıcı hiçbir şey görmez.

Hafif kod inceleme kültürü

GitHub flow dokümantasyonu, küçük PR pratiğinin somut karşılığını şöyle tarif ediyor: "İdeal olarak her commit izole ve tam bir değişiklik içerir... bir değişkeni yeniden adlandırmak ve bazı testler eklemek istiyorsanız, değişken adını bir commit'e, testleri başka bir commit'e koyun." Aynı dokümantasyon, dal oluşturmanın amacını da netleştiriyor: "Bir dal oluşturarak, varsayılan dalı etkilemeden çalışabileceğiniz bir alan yaratırsınız... aynı zamanda işbirlikçilerinize çalışmanızı inceleme şansı verirsiniz." Küçük, izole commit'ler hem review'u hızlandırır hem trunk'ı sürekli sağlıklı tutar.

Hibrit: Release Dalı + Trunk (Release Train)

Saf git-flow de saf trunk-based de mobil dağıtım kısıtlarına doğrudan oturmuyor; ikisi arasında bir hibrit bu kısıtlara daha kolay uyum sağlıyor. trunkbaseddevelopment.com'un "branch-for-release" sayfasında anlatılan pratik, mobil ekipler için doğal bir hibrit oluşturur: günlük geliştirme tek bir main üzerinde, kısa ömürlü dallarla devam eder; yayına birkaç gün kala bir release/x.y dalı kesilir ve bu dal dondurulur — yalnızca hedeflenmiş cherry-pick düzeltmeleri kabul eder. Ben genelde mobil projelerde bu düzeni "release train" olarak adlandırmayı tercih ediyorum: tren belirli bir tarihte kalkar, o ana kadar trunk'a giren her şey trene biner, kalanlar bir sonraki treni bekler.

1# Release train: yayından birkaç gün önce (ör. 5 gün) dal kes, dondur
2git checkout main
3git pull origin main
4git checkout -b release/4.12.0
5git push origin release/4.12.0
6 
7# Trunk'ta geliştirme devam eder (4.13.0 için)
8# release/4.12.0'a yalnız cherry-pick ile hata düzeltmesi girer
9git checkout release/4.12.0
10git cherry-pick <hotfix-commit-sha>

Bu akışta trunk asla "dondurulmuş" olmaz; sadece belirli bir anlık görüntüsü mağazaya gider.

Sürüm Numaralandırma ve Dal Adlandırma

Release train'i sürdürülebilir kılan şey çoğu zaman disiplinden çok isimlendirmedir. Ben genelde release dallarını semver'e birebir bağlıyorum — release/4.12.0 gibi, release/sprint-42 ya da tarih bazlı bir isim değil, çünkü sürüm numarası mağaza incelemesine giden build ile bire bir eşleşmeli ve build numarasıyla karıştırılmamalı. Aynı mantık trunk'taki geliştirme dalları için de geçerli: kısa ömürlü bir dal feature/onboarding-v2 gibi neyi yaptığını anlatmalı, kimin açtığını değil — çünkü trunk-based'de dal zaten birkaç saat ile birkaç gün arası yaşıyor, kalıcı bir referans noktası olması beklenmiyor. Cherry-pick geçmişini takip etmek istiyorsan, her cherry-pick commit mesajına orijinal trunk commit SHA'sını eklemek işe yarar; bu sayede bir hata düzeltmesinin hem main'de hem release/4.12.0'da hangi commit olduğunu ayrı bir araç kullanmadan git log'dan okuyabilirsin. Release dalı kapandığında (yani bir sonraki sürüm train'i başladığında) eski release dalını hemen silme — mağaza incelemesi reddedilirse ya da acil bir hotfix gerekirse, o dalın hâlâ orada durması geri dönüşü hızlandırır.

Karar Çerçevesi

Karar için üç eksen kullan: ekip boyutu, sürüm sıklığı ve kaç sürümü aynı anda desteklemen gerektiği. DORA'nın üç kuralı (3 veya az aktif dal, günde en az bir trunk merge, code freeze yok) ve Driessen'in ikili ayrımı (sürekli teslimat → basit akış; açıkça sürümlenen/çoklu sürüm desteği → git-flow) bu tabloyu doğrudan besliyor.

Geçiş Planı: Git Flow'dan Trunk-Based'e 4 Hafta

Bu geçiş planı, resmi tek bir kaynaktan gelmiyor; DORA'nın CI ön koşulları, feature flag pratiği ve "3 veya az aktif dal" hedefi üzerine kurduğum uygulanabilir bir sıralama.

Hafta 1: CI'yi günlük çalışır hale getir

Önce trunk'a güvenebilmen lazım. DORA'nın kuralı net: build ve testler günde en az bir kez başarıyla çalışmalı. develop dalına giren her PR için otomatik test hattı yoksa, önce bunu kur.

Hafta 2: Dal sayısını 3'e indir

Açık feature dallarını listele, hangilerinin haftalardır beklediğini gör. DORA'nın "3 veya daha az aktif dal" hedefine göre, kalan işleri ya bitir ya da feature flag arkasına alıp trunk'a erken birleştir.

Hafta 3: Feature flag altyapısını kur

Remote config tabanlı basit bir flag sistemi (Firebase Remote Config, LaunchDarkly ya da kendi çözümün) kur. Yarım kalan işleri artık develop yerine flag arkasında main'e taşı.

Hafta 4: İlk release train'i çalıştır

develop dalını kaldır, main'i tek geliştirme hattı yap. İlk mağaza sürümünde release/x.y dalını dene, sadece cherry-pick kabul ettiğini ekiple netleştir.

Sık Hatalar

• Ağır code review süreci ile trunk-based denemek: DORA'nın işaret ettiği en büyük engel bu — çok onaylı, yavaş review süreci varken trunk-based'e geçmeye çalışmak, küçük PR disiplinini imkansız kılar.
• CI'siz trunk-based: Günlük build/test garantisi olmadan herkesin doğrudan main'e commit atması, kırık trunk riskini büyütür.
• Feature flag'i unutup yarım işi trunk'ta bırakmak: Flag altyapısı yoksa, "yarım özellik trunk'a giremez" düşüncesiyle yine uzun ömürlü dallara dönülür.
• Release dalına yeni özellik sızdırmak: Wingerd & Seiwald'ın 1998'den gelen ilkesi hâlâ geçerli — release dalı devam eden geliştirme çalışması almamalı. Bir kez sızarsa, dal "ikinci trunk"a dönüşür ve amacını kaybeder.
• Git-flow'u sadece "eski" olduğu için terk etmek: Driessen'in 2020 notu bir yasak değil, bir bağlam ayrımı. Çoklu sürüm destekleyen mobil ürünlerde git-flow hâlâ meşru bir seçim.
• Hibrit modeli belgesiz bırakmak: Release train kullanıyorsan, "trunk'a ne zaman ne girer, release dalına ne zaman cherry-pick yapılır" kuralını ekip wiki'sine yazılı olarak koy; sözlü anlaşma unutulur.

SSS

Git Flow ile trunk-based development arasındaki fark nedir?

Temel fark dal ömrüdür. Git flow, master ve develop adlı iki sonsuz ömürlü ana dal ile bunların üzerine kurulu feature/*, release/*, hotfix/* dallarını kullanır. Trunk-based development ise tek bir uzun ömürlü dal (main/trunk) üzerinde çalışır; dallar genellikle birkaç saatten fazla yaşamaz ve geliştiriciler sık sık doğrudan trunk'a merge eder.

Mobil uygulama ekipleri için hangi dallanma stratejisi daha uygun?

Tek doğru cevap yok; Driessen'in 2020 notundaki ayrıma göre karar verilir. Sürekli teslimat yapan, tek aktif sürümü olan ekipler trunk-based'e (gerekirse release train hibritiyle) daha uygundur. Aynı anda birden fazla mağaza sürümünü desteklemesi gereken, düzenli QA fazına ihtiyaç duyan ekiplerde git flow ya da git flow'a yakın bir release dalı yapısı hâlâ meşrudur.

Trunk-based development için feature flag zorunlu mu?

Kesin bir zorunluluk olmasa da, trunkbaseddevelopment.com'un tarif ettiği pratik açısından pratikte gereklidir. Yarım kalan bir özelliği uzun ömürlü bir dalda saklamak yerine, Fowler'ın "Feature Toggles" dediği tekniği kullanarak trunk'a erken ve kapalı halde entegre etmek, trunk-based'in "kısa ömürlü dal" ilkesini sürdürülebilir kılar.

Release dalı ile hotfix dalı aynı şey mi?

Hayır. Release dalı, yayına hazırlanan bir sürümün dondurulmuş anlık görüntüsüdür ve yalnız hedeflenmiş düzeltmeler alır (Wingerd & Seiwald, 1998). Hotfix dalı ise git flow'a özgü, master'daki üretimde bir hatayı acilen düzeltmek için açılan kısa ömürlü bir daldır. Trunk-based'de aynı ihtiyaç, release dalına doğrudan cherry-pick yapılarak karşılanır.

CI'ım henüz olgun değilse trunk-based'e geçmeli miyim?

Hayır, önce CI'yi olgunlaştır. DORA'nın kuralı, build ve testlerin günde en az bir kez başarıyla çalışmasını şart koşar; bu garanti yokken herkesin doğrudan main'e commit atması, kırık bir trunk riskini büyütür. Geçiş planındaki 1. haftayı (CI'yi günlük çalışır hale getirme) atlamadan ilerleme.

Güncelleme (Eylül 2026)

Bu makale 16 Eylül 2026 itibarıyla güncel araçlarla yazıldı; yazım anına yakın, dallanma disiplinini doğrudan etkileyen gelişmeler şunlar:

• 9 Eylül 2026 — GitHub, sırları açık PR'ların merge'ini engelleyen kural ekledi. Repository ruleset'lerine "require secret scanning alerts are resolved" adlı yeni bir kural geldi (şu an public preview'da, GitHub Secret Protection ya da GitHub Advanced Security aboneliği gerektiriyor): bir PR'ın head commit'i için secret scan tamamlanmamışsa ya da açık alert varsa, merge engellenir. Trunk-based ekiplerde "her commit sağlıklı olmalı" ilkesini otomatikleştiren bir adım. Kaynak: github.blog changelog.
• 11 Ağustos 2026 — GitHub, eski branch protection kurallarını repository ruleset'lerine otomatik taşıyan bir araç sundu. Settings → Branches altında "Convert to ruleset" ile mevcut kurallar (zorunlu review'lar, status check'ler, push kısıtlamaları) desen bazlı ruleset'lere eşleniyor; trunk-based ekipler için mevcut koruma kurallarını yeni ruleset modeline taşımayı kolaylaştırıyor.
• 28 Nisan 2026'dan beri — App Store Connect'e yüklenen iOS/iPadOS uygulamaları iOS 26 & iPadOS 26 SDK veya sonrasıyla derlenmiş olmalı. CI runner'ı eski bir Xcode image'ına sabitlenmiş ekipler için bu, release train'e yeni bir "toolchain kapısı" ekliyor: dal stratejisinden bağımsız olarak CI image'ının güncel tutulması artık submission'ın ön koşulu.
• 10 Mart 2026 — DORA, yüksek AI benimsemesinin hem teslimat throughput'unu hem de teslimat istikrarsızlığını artırdığını yazıyor. dora.dev'in "Balancing AI Tensions" raporuna göre AI, mevcut güçlü ve zayıf yönleri büyüten bir "amplifier" gibi çalışıyor. Bunu dal disiplini tarafından okursan: DORA'nın 3-veya-az-aktif-dal ve günlük trunk merge kuralları, AI destekli geliştirmede daha da belirleyici hale gelebilir.

Sonuç

Git flow trunk based development farkı, kısaca dal ömrüne ve mobil ekibin gerçek dağıtım kısıtlarına indirgenir. Driessen'in kendi 2020 notu bile git-flow'u toptan reddetmiyor; sürüm sıklığın, aynı anda desteklediğin build sayın ve CI olgunluğun kararı belirlemeli. Trunk-based'e geçmeyi düşünüyorsan önce CI ve feature flag altyapını kur, sonra release train hibritini dene.

Konuyu derinleştirmek için şu yazılara bakabilirsin: CI/CD hattını sıfırdan kurmak istiyorsan iOS CI/CD Pipeline: GitHub Actions ve Fastlane rehberine göz at. Mobil ekipte DevOps pratiklerini bütün olarak gözden geçirmek için Mobile DevOps Best Practices yazısı iyi bir başlangıç. Apple'ın kendi CI çözümünü kullanıyorsan Xcode Cloud Pipeline Optimization build sürelerini ve maliyeti nasıl düşüreceğini anlatıyor. Release train'de crash oranını izlemek için iOS Crash Reporting ve Analytics rehberine bakabilirsin.

Mağaza submission sürecini otomatikleştirmek istersen App Store Connect API 2026 yazısı TestFlight ve submission otomasyonunu detaylandırıyor. Modüler mimariyle trunk-based'i birlikte yürütmek istersen Modular iOS Architecture ve Swift Package Manager yazısını da incele.

İki modelin özet tablosu ve kısa karar rehberi için Git Flow vs Trunk-Based karşılaştırma sayfasına da göz atabilirsin.

Kaynaklar

• A successful Git branching model — nvie.com — Git flow'un orijinal tanımı ve Vincent Driessen'in 2020 tarihli "reflection" notu.
• Trunk Based Development — trunkbaseddevelopment.com — Trunk-based development'ın tanımı, Google örneği ve terminoloji geçişi.
• Branch for release — trunkbaseddevelopment.com — Just-in-time release dalı pratiği ve dondurulmuş dal kuralı.
• Feature Flags — trunkbaseddevelopment.com — Feature toggle tekniği ve Martin Fowler referansı.
• Trunk-based development — dora.dev — DORA'nın üç dal-hijyeni kuralı ve yaygın engeller.
• Continuous integration — dora.dev — Günlük build/test kuralı ve 2015 State of DevOps bulgusu.
• GitHub flow — GitHub Docs — Hafif, dal-tabanlı iş akışı ve küçük commit ilkesi.
• 5 Effective Git Branching Strategies — DeployHQ — nvie'nin 2020 notuna atıf yapan bir rehber.
• Block pull requests with exposed secrets from merging — GitHub Changelog — 9 Eylül 2026, secret scanning merge kuralı.
• Automatically migrate branch protection rules to repository rulesets — GitHub Changelog — 11 Ağustos 2026, branch protection'dan ruleset'e otomatik dönüşüm aracı.
• Upcoming SDK minimum requirements — Apple Developer — 28 Nisan 2026'dan beri geçerli iOS/iPadOS/tvOS/visionOS SDK minimum sürüm zorunluluğu.
• Balancing AI Tensions — dora.dev — 10 Mart 2026, AI benimsemesinin teslimat hızı ve istikrarsızlığına etkisi.