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

> Uzun ömürlü dalları kaldırıp değişiklikleri küçük parçalar hâlinde main'e alın, bitmemiş işi kapalı bir flag arkasında tutun ve biten flag'i temizleyin.

- Soruldu: 2026-06-12
- Yanıtlandı: 2026-06-12
- Soran: Tarık
- Etiketler: ci-cd, git, mimari
- Kaynak: https://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.

## Kısa cevap

Mesele şu: kodu sık merge etmek istiyorsunuz ama yarım işin canlıya kaçmasını da istemiyorsunuz. Bu çelişkinin köprüsü flag'ler. Dal, merge ve PR disiplininin üretimdeki karşılığını [Git rehberinde](/tr/blog/production-git-senior-pratik-rehberi/) topluca ele almıştım; buradaki geçiş o disiplinin üstüne kurulur.

## Neden

1. **Uzun ömürlü dallar problemin kendisi.** `feature`/`develop`/`release` dalları zamanla ana daldan uzaklaşır; conflict ve haftalara yayılan release tam buradan doğar.

2. **Flag, deploy'u release'den ayırır.** Kodu istediğiniz an deploy edersiniz (deploy), özelliği hazır olunca açarsınız (release). Bu ayrım size flag bazında canary/kademeli açılım da kazandırır — aynı sürümü %5 kullanıcıya açıp izleyebilirsiniz.

3. **Temizlenmeyen flag'ler yeni bir borç yaratır.** Ölü flag'ler kendileri birer teknik borca dönüşür ve kod tabanını çorbaya çevirir; yani flag'i kalıcı bir yapı olarak görmek, çözdüğü problemin yerine bir yenisini koyar.

## Ne yapmalı

1. **Uzun ömürlü dalları kaldırın, değişikliği sürekli main'e alın.** Trunk-Based'de değişiklikleri küçük parçalar halinde **sürekli** main'e alırsınız; dal ömrü kısaldıkça conflict de release süresi de kendiliğinden düşer.

2. **Bitmemiş işi flag arkasında "karanlıkta" tutun.** Tamamlanmamış özelliği prod'da kapalı bir flag'in arkasına koyun, kodu yine de günlük main'e merge edin. Özellik bitip test edilince flag'i açarsınız. Böylece kod canlıda olur ama kullanıcıya görünmez.

3. **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 temizleyin.

**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.

## İlgili Yazılar

- [Trunk-Based Development'a Ne Zaman Geçiyorum?](https://sade.dev/tr/journal/trunk-based-ne-zaman-geciyorum) — sade.dev
- [Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını nasıl tasarlarım?](https://muhammetsafak.com/tr/sor-bakalim/hata-artisinda-otomatik-rollback-ve-kendi-kendini-iyilestiren-deploy/) — Sor Bakalım
- [Fintek API'si için Canary mi, Blue-Green deployment mı?](https://muhammetsafak.com/tr/sor-bakalim/canary-mi-blue-green-mi-fintek-api-icin-deploy-stratejisi/) — Sor Bakalım
- [CI/CD'de OIDC ve IAM Role ile şifresiz (secretless) AWS erişimini nasıl kurarım?](https://muhammetsafak.com/tr/sor-bakalim/ci-cd-de-secret-yonetimi-ve-oidc-ile-sifresiz-erisim/) — Sor Bakalım