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” derken

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 o ritmde 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 ütopi.
  2. Feature flag altyapısı. Yarım bitmiş özelliklerin koda girip kullanıcıya kapalı kalması bu modelin temeli. Boolean bayraktan 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 15 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.

Geçmediğim durumlar

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 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 pratik tarafını daha önce Production’da 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 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.