# Trunk Tabanli Gelistirme: TBD vs Gitflow 2026 Rehberi URL: https://codebasechat.com/tr/journal/trunk-tabanli-gelistirme-tbd-gitflow-rehberi-2026 Type: blog Locale: tr Published: 2026-09-22 Updated: 2026-09-22 --- > Trunk tabanli gelistirme, günde en az bir kez main dalında bileştirilen dallandırma stratejisidir. Uzun ömürlü dalları ortadan kaldırır ve entegrasyon çatışmalarını azaltır. ## Trunk Tabanli Gelistirme Nedir? Trunk tabanli gelistirme, her gelistiricinin tek bir paylaşılan dala (genellikle `main` veya `trunk` olarak adlandırılır) gün içinde en az bir kez bileştirdiği bir dallandırma stratejisidir. Uzun ömürlü özellik dalları yoktur. Kod her zaman üretime hazır durumda kalır. Bir özellik hazır değilse, onu kullanıcılardan saklamak için bir özellik bayrağı kullanılır; ekipten izole etmek için bir dal değil. İşte kısa versiyonu. Uzun versiyon, mevcut iş akışınızın fark ettiğinizden daha fazla riski oluşturabilir neden bunu açıklar. Bu stratejinin arkasındaki düşünce, yazılım geliştirmede hız ve güvenliği dengelemektir. ## Uzun ömürlü dallar neden bir yük haline gelir? Çoğu ekip sürüm kontrolünü özellik dalları aracılığıyla öğrenir: bilet başına bir dal, inceleme sonrasında bileştirilir. Düzenli görünür. Fakat bu yaklaşım skallandığında sorunlar ortaya çıkar. Bir dal 24 saatten fazla yaşarsa, meslektaşlarınızın main'e yaptığı her commit, henüz görmediğiniz bir gelecekteki çatışmadır. Sekiz mühendisli bir ekipte, her biri iki haftalık bir dal tutarsa, tek bir entegrasyon yürütmüyorsunuz. Sekiz paralel dünyayı yönetiyorsunuz ve her gün biraz daha farklılaşıyorlar. Bileştirme günü bir görev değil. Bu bir müzakere. Dosyalar değiştiğinde, hangi versiyonun doğru olduğu belirsiz hale gelir. DORA araştırması (binlerce ekip arasında yapılan yazılım teslimat performansı hakkındaki en büyük boylamsal çalışma) burada sert bir çizgi çizer: 24 saatten fazla yaşayan dallar, daha düşük dağıtım sıklığı ve daha yüksek değişiklik başarısızlık oranları için ön belirtisidir. En iyi performans gösteren ekipler günde birden fazla kez entegre olur. Kalanlar özellik "yapılmış" olduğunda bileştirir; bu genellikle hiç temiz olmadığı anlamına gelir. Gizli maliyet, bileştirme çatışmasının kendisi değil. Kodun yazıldığından üç hafta sonra onu çözümlemek için gereken bağlam değiştirmedir. Hiç kimse niyet neydi hatırlamaz. Bir geliştirici, haftalardır bitmemiş bir özellik üzerinde çalışırken, diğer geliştiriciler aynı dosyaları düzenlemiştir. Bu durumda conflict resolution saatler alabilir. ## Trunk tabanli gelistirme gerçekte nasil çalişir? Mekanik basit fakat disiplin gerektirir. Main'i çekersiniz. Küçük, tutarlı bir değişiklik yaparsınız. Test paketini çalıştırırsınız. Main'e itersiniz. Tüm bunlar öğle yemeğine gitmeden önce gerçekleşir. Bu döngü tekrar tekrar uygulanır. Küçük bir repo üzerinde solo katkıda bulunan biri için, bu zaten nasıl çalıştığıdır. 300K satır kod monorepo'sunda yirminci kişi olan bir ekip için, üç uygulamanın birlikte çalışması gerekir: **Kısa ömürlü dallar (isteğe bağlı ama yaygın)**: Bazı ekipler dalların iki güne kadar yaşamasına izin verir ve bileştirmeyi zorlar. Bu, çok haftalık sapma oluşturmadan kod inceleme kültürünü korur. Dal, izolasyon mekanizması değil, inceleme aracıdır. Mühendisler hala PR açarlar, fakat bu PR hızlı biteceği kesindir. **Her itişte sürekli entegrasyon**: Main'e her commit, tam bir yapı ve test paketini tetikler. Kırılırsa, iki haftalık bir özellik dalı Cuma saat 16:00'de indiğinde değil, dakika içinde kırılır. Böylece sorun hemen tespit edilir. **Tamamlanmamış işler için özellik bayrakları**: Bitmeyen özellikler bir bayrak arkasında üretime gönderilir. Kullanıcılar hiçbir şey görmezler. Ekip her şeyi entegre eder. Bu, çoğu ekibin atladığı parçadır; bu yüzden ilk TBD deneyleri başarısız olur. Ekip bileştirmek ister ama özellik henüz hazır değil. Feature flag olmadan, bu imkansızdır. Bu uygulamaların hiçbiri trunk tabanli gelistirme'ye özgü değil. Fark, TBD'nin hepsini zorunlu yerine isteğe bağlı kılarken zorunlu kılarıdır. Tüm üç parça birlikte çalıştığında model başarılı olur. ## Özellik bayrakları: TBD'yi işletmeyi sağlayan mekanizma ![Özellik bayrağı panosu göz önünde tutarken dizüstü bilgisayar klavyesinde geliştirici elleri](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) Özellik bayrağı, kodunuzdaki çalışma zamanında değerlendirilen koşullu ifadedir. Bayrak kapalı olduğunda, yeni kod yolu yürütülmez. Açık olduğunda, belirli bir kullanıcı, trafiğin yüzdesinde veya tüm kullanıcı tabanında, uygulanır. Basit bir boolean kontrol gibi görünse de, bu mimari bir kaymadır. Bu önemsiz görünüyor. Sonuç değil: dağıtımı serbest bırakmaktan ayırabilirsiniz. Kod sürekli üretime gönderilir. Özellikler hazır olduğunda veya on saniye içinde kapatmanız gerekiyorsa hiç açılmazsa piyasaya sürülür; üç haftalık commitleri geri almak yerine. Rollback anında gerçekleşir. Minimum uygun kurulum üç şey gerektirir: bayrakları tanımlamanın bir yolu, çalışma zamanında değerlendirmenin bir yolu ve yeniden dağıtmadan bunları değiştirmenin bir yolu. Düz bir JSON config dosyası üç kişilik bir ekip için çalışır. Bayraklar "Almanya'daki beta kohortundaki kullanıcılar için etkin" gibi hedefleme kurallarına ihtiyaç duymaya başladığında, on mühendis civarında adanmış bir özellik yönetimi hizmeti karmaşıklığını haklı çıkarır. Pazarda LaunchDarkly, Atlassian, Unleash ve Harness gibi seçenekler bulunur. Takip etmek için bir şey: bayrak borcu. Özellik piyasaya sürüldükten sonra hiçbir zaman temizlenmeyen bayraklar koşullu spagetti haline gelir. Kod basında karmaşıklık artar. TBD'yi doğru yapan bir ekip, her bayrağı özelliğin tamamen başlatılmasından bir sprint içinde kaldırır. Bayrakları kalıcı yapılandırma değil, geçici iskeleme olarak düşünün. ## TBD vs Gitflow: 2026 için doğrudan karşılaştırma Gitflow, üç ayda bir gönderilen kutu yazılımı için 2010 yılında tasarlanmıştır. Sürümleri uzun ömürlü dallar olarak modeller. Günde veya saat başı dağıtan ekipler için, bu model artık eşlenmez. Modern SaaS şirketleri için hantaldır. CI/CD çalıştıran bir ekip için karşılaştırma şöyle görünür: **Dal ömrü**: Gitflow günler ila haftalar boyunca çalışır. TBD saatler ila en fazla 1-2 gün boyunca çalışır. **Bileştirme çatışmaları**: Gitflow sık, yüksek şiddetli çatışmalar üretir. TBD, entegrasyon boşlukları saatler ve haftalar olmadığından, nadır, düşük şiddetli olanları üretir. **Dağıtım sıklığı**: Gitflow dağıtımı bir sürüm dalına bağlar. TBD dağıtımı serbest bırakmaktan tamamen ayırır. İstediğiniz zaman üretime gönderebilirsiniz. **Geri alma mekanizması**: Gitflow dal bileştirmesini geri alarak geri alır. TBD özellik bayrağını kapatarak geri alır. **Onboarding karmaşıklığı**: Gitflow gelişme/ana/hotfix kurallarını anlamayı gerektirir. TBD'nin bir dalı vardır: main. **Gerekli CI yatırımı**: Gitflow düşüktür (dallar riski absorbe eder). TBD yüksektir (main her zaman yeşil kalmalıdır). Gitflow her bağlamda yanlış değil. Bir uygulama mağazasında bir mobil uygulamayı gönderiyor ve dakikalar içinde düzeltmeler gönderemezseniz, bir sürüm dalı modeli mantıklıdır. Dağıtımları kontrol ettiğiniz bir SaaS çalıştırıyorsanız, güvenlik eklemeden koordinasyon maliyeti ekleyen ekstra dallandırma yapısı havadır. ## DORA metrikleri dallandırma stratejileri hakkında ne söylüyor? ![Paylaşılan bir ekranda eş programlama ve kod incelemesi yapan iki mühendis](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) [DORA DevOps Durumu araştırması](https://dora.dev/research/) 2014 yılından bu yana yazılım teslimat performansını izlemektedir. Burada doğrudan alakalı olan verilerden iki bulgu vardır. İlk olarak, trunk tabanli gelistirme DORA modelinde yazılım teslimat performansını tahmin eden 24 yeteneğinden biridir. "Sürekli teslimat" kümesi altında yer alır; bu, DORA'nın bunu ekip tercihi değil, altyapı uygulaması olarak değerlendirdiği anlamına gelir. Bu araştırma binlerce şirketi kapsadı. İkincisi, en iyi performans gösteren ekipler günde birden fazla kez dağıtır. Düşük performans gösteren haftada bir veya ayda bir dağıtırlar. Uzun ömürlü dallar ve seyrek entegrasyon, yıllar boyunca birden fazla veri dağılımının daha yavaş ucunda görünür. Bu tutarlı bir bulgudur. Araştırmanın iddia etmediği şey: TBD elit performans nedeni oluşturmaktadır. TBD'yi başarıyla benimseyen ekipler zaten otomatik testlere, çalışan bir CI boru hattına ve küçük commitlere alışkanlığı olan ekipler olma eğilimindedir. Trunk tabanli gelistirme bu boşlukları eksik ise hemen ortaya koymaktadır. Hiçbir CI olmayan ve %40 test kararsızlığı olan bir ekip TBD'ye geçişten fayda görmeyecektir. Sadece main'i daha sık kıracaklardır. ## Trunk tabanli gelistirme nerede mantıklı olmamaya başlar? TBD'nin içinde çıkardığından daha fazla sorun yarattığı üç senaryo: **Zorunlu ön yayın onay kapıları içeren yüksek düzenlenmiş ortamlar**: Her yayın, gönderilmeden önce uyumlu onay gerektiriyorsa, üretime sürekli dağıtım zaten engellenir. Dallandırma modeli ikincil hale gelir. Dallandırma stratejisi ne olursa olsun değişiklikleri toplu olarak yapacaksınız. Bu durum banka, sigorta ve sağlık sektörlerinde yaygındır. **Zayıf test paketleri**: TBD hızlı, güvenilir bir CI boru hattı gerektirir. Yapılar 45 dakika sürüyor ve %20 kararsızlığı varsa, geliştiriciler beklemeyi önlemek için commitleri toplu olarak yapacaktır. Bu modeli yener. Kısıtlama, dallandırma kuralı değil, test altyapısıdır. **Tutarsız kod sahipliğine sahip çok büyük ekipler**: 50+ kişilik ekiplerde her takım farklı bir hizmete sahip olmadığında, TBD hizmet düzeyinde iyi çalışır. Bunu herkesin her şeye dokunduğu paylaşılan bir monorepo'ya uygulamak, strict linting kuralları ve CI sahipliği kuralları gerektirir; main temiz kalmasını sağlar. Her üç durumda da, çözüm farklı bir dallandırma stratejisi değil. Çözüm temel altyapı sorunu. TBD sadece sorunu daha hızlı görünür kılar. ## Dağıtımları durdurmadan nasıl geçiş yaparsınız? Ekiplerin yanlış yaptığı geçiş: TBD'yi duyurur, özellik dalı kuralını siler ve main'in ilk haftada kırıldığını izlersiniz. Bu tehlikeli ve motivasyon kırıcıdır. Daha güvenli bir yol: - **Mevcut dalları tutun, ömür kuralı ekleyin**: Hiçbir dal 3 günden fazla yaşamaz. Bu, sık entegrasyon baskısını zorlar; ışıkları kapatmaz. Ekip yavaş yavaş alışır. - **CI'nizi ilk kez enstrüman edin**: Bileştirme hızlı olmadan, bileştirme güvenli olmalıdır. Test paketinin yeşil olduğundan, 15 dakikada çalıştığından ve main dalında başarısızlıkta engellediğinden emin olun. - **Bir özelliği bir bayrak ile kaplamak için seçin**: Bunu her tamamlanmamış özellik için ihtiyaç duymadan önce bayrak yönetimi kas hafızasını oluşturun. - **Dal ömrünü hafta ile hafta küçültün**: 3 günden 2 güne, 1 güne altı hafta boyunca. Bileştirme çatışması sıklığını ön gösterge olarak izleyin. Düştüğünde, model çalışıyor. - **Eski kuralı sadece yeni kuruş çalıştığında retires**: Gitflow kuralları pilot dışında her şey için yerinde kalır. 6-8 hafta boyunca her iki modeli de çalıştırmak gayet iyi. ## TBD'nin yapışkanlığını tahmin eden tek alışkanlık ![Yeşil dağıtım durum göstergeleri ile CI/CD boru hattı panolarını izleyen mühendis](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) Trunk tabanli gelistirme ekipler main'e bileştirmeyebildikleri için başarısız olmaz. Geliştiricilerin işi bir günde gemi yapacak kadar küçük kapsamda alışkanlıkları olmadığı için başarısız olur. Bu ekibin organizasyonu hakkında bilginizi gerektirir. Temel kaymış teknik değil. Bu, planlama sırasında işin nasıl tanımlandığıdır. "Yeni ödeme akışını uygula" diyen bir hikaye iki haftalık bir dal bekliyordur. "Rota işleyicisini ekle ve `payment-v2` bayrağının arkasında bir 501 döndür" diyen bir hikaye yarım günlük bir committir. Bu, çoğu ekibin oluşturmadığı PM katılımı ve arzu yönetimi kalitesi gerektirir. Dallandırma strateji değişikliği duyurmak için bir gün alır. Kapsama disiplini oluşturmak altı ay alır. Bunu takip eden ekipler başarılı olur. Ekibin zaten günde üretime çalışan yazılım gönderiyorsa, TBD zaten yaptığınız şeyleri formalleştirmeniz. Ekip her iki hafta büyük bir bileştirmede gönderiyor, TBD temel altyapı teslimat alışkanlıkları değişene kadar rahat olmayacaktır. TBD'ye yapışan ekipler, geçişten önce üç şeye yatırım yaptılar: sub-15 dakikalık bir CI boru hattı, çalışan bir özellik bayrağı hizmeti ve sprint seremonileri; bir gün içinde kapatılabilen hikayeleri üret. Bunlar üçü olmadan, dallandırma kuralı yanlış kaldıraç. ## TBD iş akışlarını çalıştırmaya yardımcı araçlar Ekip düzeyinde trunk tabanli gelistirme, daha fazla eşzamanlı hizalama anlamına gelir: entegrasyon sapmasını yakalamak için hızlı standuplar, bayraklar ve CI kuralları için belgelenmiş kurallar ve kritik yollar için eş inceleme çağrıları. Koordinasyon önemli hale gelir. ## FAQ ### Trunk tabanli gelistirme tam olarak nedir? Trunk tabanli gelistirme, her geliştirici tarafından günde en az bir kez main dalında kod bileştirilen bir dallandırma stratejisidir. Uzun ömürlü özellik dalları yoktur ve tamamlanmamış özellikler özellik bayrakları arkasında gizlenir. ### Gitflow ile trunk tabanli gelistirme arasında fark nedir? Gitflow uzun ömürlü sürüm dalları kullanır ve üç ayda bir yayın modeline uygun şekilde tasarlanmıştır. TBD günde birden fazla bileştirme gerektirir ve dağıtımı serbest bırakmaktan ayırır. TBD hızlı, sürekli dağıtım yapan şirketler için uygundur. ### Özellik bayrakları nedir ve neden önemlidir? Özellik bayrağı, kodunuzdaki çalışma zamanında değerlendirilen koşullu ifadedir. Dağıtımı serbest bırakmaktan ayırır. Tamamlanmamış özellikler üretimde gizli kalabilir ve kullanıcılar onları görmez. ### TBD hangi durumlarda uygun değildir? Yüksek düzenlenmiş ortamlarda (banka, sigorta), zayıf test paketleri olan ekiplerde, veya 50+ kişilik tutarsız kod sahipliği olan ekiplerde TBD tercih edilmeyebilir. Temel sorun, dallandırma stratejisiyle değil altyapıyla ilgilidir. ### DORA araştırması TBD hakkında ne söylüyor? DORA araştırması, trunk tabanli gelistirme'nin yazılım teslimat performansını tahmin eden 24 yeteneğinden biri olduğunu bulmuştur. En iyi performans gösteren ekipler günde birden fazla kez dağıtırken, düşük performans gösteren ekipler ayda bir dağıtır. ### TBD'ye geçiş yaparken neler yapmalı? TBD'ye geçişte kademeli bir yaklaşım izleyin: önce dal ömrü kuralları ekleyin, CI boru hattını güçlendirin, özellik bayrakları ile pilot yapın, sonra dallandırma kurallarını azaltın. 6-8 hafta boyunca her iki modeli de çalıştırmak normaldir. ### TBD'nin başarısı ne tahmin eder? TBD'nin başarısı, teknik değil sosyal faktörlere bağlıdır. Ekip işleri gün içinde tamamlayacak kadar küçük kapsamda tanımlamalıdır. Bunu sağlamak için PM katılımı ve 6 aylık disiplin gereklidir. ### Bayrak borcu nedir ve nasıl yönetilir? Bayrak borcu, özellik piyasaya sürüldükten sonra temizlenmeyen bayraklardır. Bu kodda karmaşıklık yaratır. Bayrakları kalıcı yapılandırma değil geçici iskeleme olarak düşünün ve her bayrağı bir sprint içinde kaldırın.