--- title: "Trunk-Based Development'a Ne Zaman Geçiyorum?" description: "Yüksek frekanslı deploy yapan ekiplerde release branch'lerinin neden kırıldığı ve trunk-based'in ne kadarının disiplin olduğu — geçtiğim ve geçmediğim eşikler." url: https://sade.dev/tr/journal/trunk-based-ne-zaman-geciyorum/ lang: tr author: "Muhammet Şafak" published: 2026-05-23 updated: 2026-09-06 section: Journal tags: ["git","workflow","deploy","decisions","opinion"] summary: "Trunk-based bir araç değil, bir tempo kararı. Haftada beş deploy'un altında release branch hâlâ bir düzen; üstünde bir engel — çünkü merge sürtünmesi lineer büyümüyor ve hotfix'in develop'a geri portu er ya da geç unutuluyor. Geçiş yalnızca dört temel üzerinde yürüyor: CI'ın garantilediği yeşil trunk, feature flag altyapısı, on dakikanın altında bir pipeline ve açıldığı gün kapanan branch'ler." --- # Trunk-Based Development'a Ne Zaman Geçiyorum? > Trunk-based bir araç değil, bir tempo kararı. Haftada beş deploy'un altında release branch hâlâ bir düzen; üstünde bir engel — çünkü merge sürtünmesi lineer büyümüyor ve hotfix'in develop'a geri portu er ya da geç unutuluyor. Geçiş yalnızca dört temel üzerinde yürüyor: CI'ın garantilediği yeşil trunk, feature flag altyapısı, on dakikanın altında bir pipeline ve açıldığı gün kapanan branch'ler. Cuma öğleden sonra prod'a 6'ncı deploy gidiyor. `release/2026.05` branch'inden alınan hotfix `develop`'a geri merge edilirken bir önceki hotfix ile çakışıyor. Üç kişilik bir kanal açılıyor, on dakika konuşuluyor, kimse "bu aslında trivial bir conflict" diye düşünmüyor — çünkü bu hafta dördüncüsü. Sahne tanıdık geliyorsa, branch stratejiniz deploy temponuza yetişemiyor demektir. ## Trunk-based ne, bir cümlede Tek bir uzun ömürlü branch (`main` ya da `trunk`), ömrü saatlerle — en fazla 1–2 günle — ölçülen feature branch'ler ve her merge'in prod'a gidebilecek kadar yeşil tutulduğu bir tempo. Bitmemiş özellikler **kodda yaşar**, kullanıcıya feature flag'le açılır. Daha fazlası yok — `release/*` branch'i yok, `develop` branch'i yok, sürüm numarasına bağlı uzun yaşayan dallar yok. ## "Yüksek frekans" ne demek? Concrete olmazsa anlamsız: trunk-based'i savunduğum projelerin ortak özelliği günde 3–10 deploy. Haftada 1 deploy yapan bir ekibin trunk-based'e geçmesi için zorlayıcı bir sebep yok — [Gitflow ya da GitHub Flow](/tr/journal/gitflow-mu-github-flow-mu) o ritimde sorunsuz çalışıyor. Eşik bende net: deploy frekansı haftada 5+ olduğunda release branch bir "düzen" değil, bir engel olmaya başlıyor. ## Release branch yüksek frekansta neden kırılıyor? Üç gerçek mekanizma: - **Merge sürtünmesi lineer büyümez.** İki branch ne kadar uzun yan yana yaşarsa, çakışma olasılığı her gün artar. Haftalık release döngüsünde bu görünür değil; günlük döngüde her merge bir mini drama. - **Hotfix yolu paralel bir tarih yaratır.** `hotfix/*` → `main` → geri `develop`'a port. Bu portu unutmak en sık görülen prod bug kaynağı; yüksek frekansta unutmamak istatistiksel olarak imkânsız. - **Review ile deploy arasındaki mesafe açılır.** Bir PR'ın "merge'lendi" anı ile prod'a düştüğü an arasında günler varsa, code review aslında prod'u değil bir staging'i değerlendirir. İki ortam aynı şey değildir. ## Bu workflow'un asıl maliyeti: disiplin Trunk-based, "branch silelim" değildir. Bir kod parçasının doğumdan emekliliğe yolculuğunu — **yazılımın yaşam döngüsünü** — daha sıkı bir tempoya bağlayan bir disiplindir. Bu disiplin olmadan yapılan trunk-based, yalnızca daha hızlı kırılan bir prod demektir. Şunlar olmadan denemeyin: 1. **Yeşil trunk, sözleşme seviyesinde.** Kırık trunk = herkesin bloklandığı an. Bunu garantileyen CI yoksa (hızlı, güvenilir test piramidi + zorunlu PR check'leri), trunk-based bir ütopya. 2. **Feature flag altyapısı.** Yarım bitmiş özelliklerin koda girip kullanıcıya kapalı kalması bu modelin temeli. Boolean flag'den profile-based rollout'a kadar bir feature flag disiplini şart. 3. **Hızlı pipeline.** Merge'den prod'a 30 dakika geçiyorsa, "her merge prod'a gidebilir" iddiası teorik. 5–10 dakika aralığı pratik eşik. 4. **Kısa ömürlü branch kültürü.** PR'ı 4 günde merge etmek trunk-based değil, gizli Gitflow. Branch açıldığı gün ya da ertesi gün kapanmalı. Bu dördü oturmadıysa, ekibe trunk-based dayatmak prod'u hızlandırmaz — yalnızca prod kazalarını hızlandırır. ## "Code review yavaşlatır" diye duyacaksınız Yavaşlatmaz, parçalar. Trunk-based PR'lar tasarımı gereği küçüktür — 200–400 satır, tek bir mantıksal değişiklik. Bu boyutta review 60–90 dakikadır. 2.000 satırlık bir PR'ı kimsenin gerçekten okumadığını bilen herkes, küçük PR'a geçişin gerçek kazancını görür. Küçük PR + feature flag, "bu özellik prod'da görünür mü" sorusunu "bu kod prod'da derlenir mi" sorusundan ayırır. İkisi farklı kararlardır; trunk-based bu ayrımı zorunlu kılar. ## Ne zaman geçmiyorum? Aynı önlem listesinin tersi geçerli. Trunk-based'e geçmediğim sahneler: - **Regüle sektörde zorunlu pre-prod sign-off.** Bir release'in compliance kapısından geçmesi gerekiyorsa, release branch teknik değil hukuki bir zorunluluk. Trunk-based onu kaldıramaz. - **Paralel sürüm bakımı.** Aynı anda 3.x ve 4.x desteklenecekse — packaged ürün, SDK, on-prem dağıtım — Gitflow'un sürüm hattı doğal cevaptır. - **CI olgunluğu yok.** Trunk-based, kırık ana branch'in maliyetini ekibe yıkar. CI yeşilini garantileyemeyen bir ekipte bu maliyet günde 1–2 saat boşa giden zaman olarak ödenir. - **3 kişiden küçük ekip, haftada 1 deploy.** Yatırım amorti olmaz; mevcut sıkıntınız trunk-based ile çözülmez çünkü zaten yoktur. ## Geçişi ölçtüğüm metrikler "İyi gidiyor" hipotez değil, ölçülmüş olmalı. Trunk-based'in çalışıp çalışmadığını şu üç metrikten okuyorum: - **Lead time for changes** — commit'ten prod'a kadar geçen p50 süre. Hedefim < 1 saat. - **Change failure rate** — prod'a giden değişikliklerin yüzde kaçı rollback ya da hotfix gerektiriyor. Hedefim < %15. - **Mean time to restore** — bozulan bir şey kaç dakikada düzeliyor. Hedefim < 30 dakika. Bu üçü kötüye giderse trunk-based'i bırakmadan önce CI ve flag disiplinini gözden geçiriyorum — sebep neredeyse her zaman orada. ## Workflow tek başına gümüş kurşun değil Trunk-based, Gitflow ya da GitHub Flow — hiçbiri tek başına prod'unuzu düzeltmiyor. Production'da branch stratejisi, code review temposu, deploy otomasyonu ve rollback hazırlığı birlikte çalışan bir bütün. Bu bütünün branch stratejisi ve commit/review hijyeni tarafını daha önce [Production'da Git: Senior'ın Pratik Rehberi](https://www.muhammetsafak.com.tr/blog/production-git-senior-pratik-rehberi/) yazısında derlemiştim; trunk-based o resimde temponun en hızlandığı uçtur. İki uç arasında nereye düştüğünüze karar vermek için, [Gitflow ile GitHub Flow arasındaki seçimi](/tr/journal/gitflow-mu-github-flow-mu) ayrı bir yazıda anlattım. --- Trunk-based bir araç değil, bir tempo kararıdır. Deploy frekansınız hangi tempoya oturuyorsa workflow'unuz da oraya oturmalı — tersi değil. Workflow'u modaya göre değil, prod'un nabzına göre seçin. ## Sık sorulanlar **Trunk-based'e geçmek ne zaman değer?** Deploy frekansı haftada beşi geçtiğinde release branch bir düzen olmaktan çıkıp engel olmaya başlıyor; trunk-based'i savunduğum projeler günde 3–10 deploy yapıyor. Haftada bir deploy yapan bir ekibin geçmesi için zorlayıcı bir sebep yok — Gitflow ya da GitHub Flow o ritimde sorunsuz çalışıyor. **Geçmeden önce nelerin oturmuş olması gerekiyor?** Dört şeyin. CI'ın garantilediği yeşil trunk, çünkü kırık trunk herkesin bloklandığı andır. Feature flag altyapısı, ki yarım iş kullanıcıya kapalı kalarak kodda yaşayabilsin. Merge'den prod'a beş-on dakikada varan bir pipeline. Ve branch'in açıldığı gün ya da ertesi gün kapandığı bir kültür. Bu dördü yoksa trunk-based teslimatı değil, prod kazalarını hızlandırır. **Trunk-based'e ne zaman geçmiyorum?** Dört durumda. Regüle sektörde zorunlu pre-prod sign-off varsa; orada release branch teknik değil hukuki bir zorunluluk. Aynı anda 3.x ve 4.x desteklenecekse. CI yeşilini garantileyemeyen bir ekipte. Ve üç kişiden küçük, haftada bir deploy yapan bir ekipte — yatırım amorti olmuyor. ## Kaynaklar - [Trunk Based Development](https://trunkbaseddevelopment.com/) — Paul Hammant - [DORA capabilities: Trunk-based development](https://dora.dev/capabilities/trunk-based-development/) — DORA - [DORA software delivery metrics](https://dora.dev/guides/dora-metrics-four-keys/) — DORA