3 Ekim 2026
Hangi Git akışı? Gitflow, GitHub Flow ve trunk-based
Gitflow, GitHub Flow ve trunk-based development arasında ürünün şekline, ekip büyüklüğüne ve deploy temposuna göre seçim yapmak için üç soru ve bir karar matrisi.
Git · Workflow
Hangi Git akışı? Üç soruyla karar
Gitflow da GitHub Flow da doğru; farklı ürün şekilleri için. Trunk-based ise bir tempo kararı. Cevap toplantıda değil, ürünün kendisinde duruyor.
İki modelin mekaniği
Gitflow ve GitHub Flow
| Konu | Gitflow | GitHub Flow |
|---|---|---|
| Branch'ler | main, develop, feature/*, release/*, hotfix/* | Tek main ve ondan dallanan kısa ömürlü branch'ler |
| Sürüm | Sürüm odaklı; her yayın için ayrı release branch | Sürüm kavramı yok; tek yaşayan sürüm prod'dakidir |
| Hotfix | Ayrı bir hotfix/* hattı | Sıraya giren bir PR |
| Doğal habitat | Mobil uygulama, SDK ve kütüphane, on-premise ya da packaged yazılım | Web uygulaması ve SaaS, iç araçlar, API servisleri |
Üç soru, bir varsayılan
Branch stratejisini ürün seçer
- Adım 1: Aynı anda kaç sürüm canlı?
Bir tane → GitHub Flow. Birden fazla → Gitflow. - Adım 2: Müşteri deploy frekansımı görüyor mu?
Hayır, istediğim zaman deploy ediyorum → GitHub Flow. Evet, sürümler arası bir sözleşme var → Gitflow. - Adım 3: Hotfix bir release'den geçmeli mi?
Hayır → GitHub Flow. Evet → Gitflow. - Adım 4: Cevaplar karışıyorsa
Ürünün şekli henüz oturmamıştır; geçici olarak GitHub Flow. Ondan Gitflow'a geçmek, tersinden küçük bir göçtür.
Ekip ve deploy temposu
Üç akış, dört durum
Dikey eksen ekip büyüklüğünü, yatay eksen deploy temposunu gösterir. Hücreler Production'da Git rehberinden ve trunk-based yazısından derlendi.
Küçük ekip ↔ Büyük ekip
-
Gitflow
Versiyonlu ürün
- Mobil uygulama, App Store dağıtımı
- Versiyonlu paket ya da kütüphane: release branch yararlı
-
Trunk-based
Rehberde: 50+ geliştirici, günde 10+ deploy
- Continuous deployment kültürü
- Feature flag altyapısı kurulu
-
GitHub Flow ya da daha basiti
3 kişilik freelance ajans
- PR'sız doğrudan çalışmak da seçenek
- 3 kişiden küçük ekipte trunk-based yatırımı amorti olmaz
-
GitHub Flow
3-15 kişilik takım
- SaaS, CI/CD kurulu
- Günde bir-iki deploy
Planlı, sürümlü yayın ↔ Sık deploy
Production'da Git rehberinden
Karar tablosu
| Durum | Tavsiye |
|---|---|
| Mobil uygulama, App Store dağıtımı | Gitflow |
| SaaS, küçük-orta takım, günlük deploy | GitHub Flow |
| 3 kişilik freelance ajans | GitHub Flow |
| 50+ geliştirici, deploy günde 10+ | Trunk-based |
| Versiyonlu paket ya da kütüphane | Gitflow |
| Plansız, “ne lazımsa o” | GitHub Flow |
Trunk-based'e ne zaman
Yazılarda iki ayrı eşik
- Trunk yazısı Deploy frekansı haftada 5+ olduğunda release branch bir düzen değil, bir engel olmaya başlıyor. Trunk-based'in savunulduğu projeler günde 3-10 deploy yapıyor.
- Gitflow yazısı Günde 5+ deploy'da GitHub Flow'un kısa ömürlü branch'leri bile sürtünme kaynağı oluyor; o eşikten sonra trunk-based.
- İpucu Haftada 1 deploy yapan bir ekip için geçmeye zorlayan bir sebep yok; Gitflow ya da GitHub Flow o ritimde sorunsuz çalışıyor.
Trunk-based hedefleri
Tempoyu taşıyan rakamlar
- 5-10 dakika Hedef: merge'den prod'a pipeline süresi
- 1-2 gün Eşik: feature branch'in en uzun ömrü
- 200-400 satır Hedef: tek mantıksal değişiklikli PR boyu
- 60-90 dakika Bu boyutta bir PR'ın review süresi
Geçmeden önce
Trunk-based'in dört temeli
- Yeşil trunk, sözleşme seviyesinde: CI ve zorunlu PR check'leri garanti eder (bekliyor)
- Feature flag altyapısı: yarım iş koda girer, kullanıcıya kapalı kalır (bekliyor)
- Hızlı pipeline: merge'den prod'a 5-10 dakika (bekliyor)
- Kısa ömürlü branch kültürü: açıldığı gün ya da ertesi gün kapanır (bekliyor)
Trunk-based ve ölçüm
Geçince ölç, şu sahnelerde geçme
Yap
- Lead time for changes için hedef: p50 < 1 saat
- Change failure rate için hedef: < %15
- Mean time to restore için hedef: < 30 dakika
- Metrikler kötüleşirse önce CI ve flag disiplinine bak
Yapma
- Regüle sektörde zorunlu pre-prod sign-off varken geçme
- Aynı anda 3.x ve 4.x desteklenecekse geçme
- CI yeşilini garantileyemeyen ekipte geçme
- 3 kişiden küçük, haftada 1 deploy yapan ekipte geçme
Eşleşme hataları
Modeli yanlış yere koymak
- Anti-pattern Üç akışı karıştırmak: develop branch, feature flag ve release branch bir arada. Üç ayrı disiplinin yarısını uygulamak, hiçbirinin avantajını almamak demek.
- SaaS'ta Gitflow develop gereksiz bir gölge prod olur; PR'lar iki kez merge edilir. Kazanılan izolasyon, ödenen sürtünmeye değmez.
- Packaged üründe GitHub Flow Eski sürümdeki müşteri hotfix istediğinde ekip olmayan bir bakım branch'ini arar.
- Karma model İki modelden birini doğru uygulamak, üçüncü bir model uydurmaktan her zaman ucuzdur.
Karar
Git workflow'unu ürüne göre seçin; ürünü workflow'a göre değil.
Seçim “hangisi modern” değil, “ürün şekliniz hangisini doğal kılıyor” sorusudur. Sürüm sayısı, müşteri tipi ya da deploy frekansı değiştiğinde karar yeniden açılır.
