# Gitflow'dan Trunk-Based'e geçerken feature flag mimarisini nasıl konumlandırırım?

> Gitflow'un uzun ömürlü dalları sürüklenir; merge'ler bu yüzden acı verir. Trunk-Based küçük değişiklikleri sürekli main'e alır, ama ancak bitmemiş özellik kullanıcıya ulaşamazsa işe yarar — feature flag'lerin işi tam budur. Deploy'u release'den ayırırsın.

- Soruldu: 2026-06-12
- Yanıtlandı: 2026-06-12
- Soran: Tarık
- Etiketler: ci-cd, git, mimari
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/gitflow-mu-trunk-based-mi-ve-feature-flag-mimarisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** 20 kişilik bir ekibiz. Gitflow'da `feature`/`develop`/`release`/`master` dalları üzerinden ilerliyoruz ama merge'ler uzun sürüyor (conflict) ve release süreleri haftaları buluyor. Continuous Delivery kültürüne geçmek için Trunk-Based'e geçmeyi planlıyoruz.

Kodun küçük parçalar halinde doğrudan ana dala gittiği bu modelde, bitmemiş özelliklerin canlıda aktif olmasını engellemek için feature flag mimarisini nasıl konumlandırırım?


Kısa cevap: Gitflow'da merge'lerin acı vermesi ve release'lerin haftalar sürmesi tam olarak uzun ömürlü dalların **sürüklenmesinden** kaynaklanıyor. Trunk-Based bunu küçük değişiklikleri sürekli main'e alarak çözer; ama "main'deki bitmemiş özellik kullanıcıya ulaşamasın" şartını feature flag'ler sağlar.

Mesele şu: kodu sık merge etmek istiyorsun ama yarım işin canlıya kaçmasını da istemiyorsun. Bu çelişkinin köprüsü flag'ler.

1. **Uzun ömürlü dallar problemin kendisi — onları kaldır.** `feature`/`develop`/`release` dalları zamanla ana daldan uzaklaşır; conflict ve haftalara yayılan release tam buradan doğar. Trunk-Based'de değişiklikleri küçük parçalar halinde **sürekli** main'e alırsın.
2. **Bitmemiş işi flag arkasında "karanlıkta" tut.** Tamamlanmamış özelliği prod'da kapalı bir flag'in arkasına koy, kodu yine de günlük main'e merge et. Özellik bitip test edilince flag'i açarsın. Böylece kod canlıda olur ama kullanıcıya görünmez.
3. **Flag, deploy'u release'den ayırır.** Kodu istediğin an deploy edersin (deploy), özelliği hazır olunca açarsın (release). Bu ayrım sana flag bazında canary/kademeli açılım da kazandırır — aynı sürümü %5 kullanıcıya açıp izleyebilirsin.
4. **Disiplin şart: kısa ömürlü dallar, güçlü CI, flag hijyeni.** Dallar bir-iki gün yaşasın, her merge'de CI sağlam çalışsın. En kritiği **flag hijyeni**: ölü flag'leri temizle, yoksa kendileri birer teknik borca dönüşür ve kod tabanını çorbaya çevirir.

**Sonuç:** 20 kişilik, Continuous Delivery hedefleyen bir ekip için doğru model Trunk-Based + feature flag'ler. Ben olsam dalları kısa tutar, her şeyi flag arkasında merge eder ve flag'leri **geçici** kabul edip biter bitmez temizlerdim. Trunk-Based'e tam olarak ne zaman ve hangi ön koşullarla geçtiğimi sade.dev'de ayrıntısıyla anlattım.