Yeni projenin ilk haftası, kick-off toplantısı, kahve daha soğumadan biri soruyor: “Hangi git workflow’unu kullanalım?” Sonraki 40 dakikada Gitflow şemaları çizilir, GitHub Flow savunulur, biri “trunk-based” der ve kimse zemin bulmadan toplantı biter.

Cevap o toplantıda değil — ürünün kendisinde duruyor.

İki modelin mekaniği, kısaca

  • Gitflow. main (prod), develop (entegrasyon), feature/* (geliştirme), release/* (sürüm hazırlığı), hotfix/* (acil yamalar). Sürüm odaklı. Bir özellik feature → develop → release → main yolunu izler.
  • GitHub Flow. Tek main ve ondan dallanan kısa ömürlü branch’ler. Her merge prod’a deploy edilebilir. Sürüm kavramı yok — tek yaşayan sürüm vardır, o da prod’daki.

İkisi de gerçek projelerde gerçekten çalışıyor. Soru hangisinin “doğru” olduğu değil, hangisinin ürününüzün şekline uyduğu.

Gitflow’un doğal habitatı

Gitflow, “aynı anda birden çok sürüm yaşıyor” gerçeği olan ürünler için tasarlandı:

  • Mobil uygulamalar — store onay süresi nedeniyle 3.4 cep telefonlarına ulaşırken 3.5 review’da, 3.6 develop’ta yaşar.
  • SDK’lar ve kütüphaneler — kullanıcının yükselme tempo’su sizin elinizde değil; 2.x’i bir süre destekliyorsunuz.
  • On-premise / packaged yazılım — müşteri “biz 4.2’deyiz” der; bu sürüme hotfix vermek bir lüks değil, sözleşme.
  • Hardware ile birlikte gönderilen yazılım — firmware ile koordine sürüm pencereleri.

Bu sahnelerde release/* branch bir bürokrasi değil, paralel zaman çizgilerinin yaşadığı yerdir. hotfix/* lane’i de “müşteri prod’da yanıyor ama biz develop’tayız” probleminin doğal cevabıdır.

GitHub Flow’un doğal habitatı

GitHub Flow ise tek yaşayan sürüm gerçeği olan ürünlerde nefes alıyor:

  • Web uygulamaları, SaaS — kullanıcının kullandığı sürüm her zaman prod’daki.
  • İç araçlar, dashboard’lar — tek bir kurulum, sürekli güncel.
  • API servisleri (versionsuz ya da rotalarla versiyonlanmış) — geriye uyumluluk koda, branch’e değil yaşar.

Burada release/* branch bir altyapı değil, gereksiz bir katmandır. Hotfix de ayrı bir lane değildir — sadece sıraya giren bir PR’dır.

Neyi gerçekten seçiyorum

Üç soruya verdiğim cevap, branch stratejisini benim yerime seçiyor:

  1. Aynı anda kaç sürüm canlı? Bir tane → GitHub Flow. Birden fazla → Gitflow.
  2. Müşteri deploy frekansımı görüyor mu? Hayır, ben istediğim zaman deploy ediyorum → GitHub Flow. Evet, sürümler arası bir sözleşme var → Gitflow.
  3. Hotfix’in prod’a giderken bir “release” üzerinden gitmesi gerekiyor mu? Hayır → GitHub Flow. Evet → Gitflow.

Üçü de aynı yöne işaret ediyorsa karar verilmiştir. Karışıyorsa, ürünün şekli henüz oturmamıştır — o zaman geçici olarak basit olanı, GitHub Flow’u seçiyorum; çünkü GitHub Flow’dan Gitflow’a geçmek, tersinden kolaydır.

Yaygın eşleşme hataları

İki modeli yanlış yere koyduğum (ya da bir başkasının koyduğunu izlediğim) durumlar:

  • SaaS’ta Gitflow. Tek sürüm yaşayan bir web app’te develop branch gereksiz bir gölge prod yaratır; PR’lar iki kez merge edilmek zorunda kalır. Sonuç: ne kazanılan izolasyon, ne ödenen sürtünme yerinde.
  • Packaged ürünte GitHub Flow. Aynı anda 3.x’i alan müşteri varken main’i 4.x ile dolduran ekip, bir hotfix istendiğinde geriye dönmek için olmayan bir branch’i aramaya başlar. Bu noktada “Gitflow’u sonradan kurmak” bir göç projesidir.
  • Karma model “kendi sürümümüzü uyduralım.” Çoğu zaman ekibin yarısının Gitflow yarısının GitHub Flow zannettiği yamalı bir şey çıkar. İki modelden birini doğru uygulamak, üçüncü bir model uydurmaktan her zaman ucuzdur.

Workflow, yazılımın yaşam döngüsünün şeklidir

Branch stratejisi bir özelliğin doğduktan kaç gün sonra prod’a vardığını, hangi koridorlardan geçtiğini, nasıl bir bakım hattında yaşlandığını belirleyen şeydir. Yani yazılımın yaşam döngüsünü — kodun değil, kararın hızını — şekillendirir.

İki şirket aynı dili, aynı framework’ü kullansın; biri Gitflow biri GitHub Flow seçtiyse aynı özelliği prod’a çıkarma süreleri tek başına bu kararla 3’e katlanır. Bu yüzden branch stratejisi tooling sorusu değil, ürün sorusudur.

İkisi de yetmediğinde

Bazı ekiplerde deploy ritmi öyle hızlanır ki — günde 5+ deploy — GitHub Flow’un kısa ömürlü branch’leri bile bir sürtünme kaynağı olmaya başlar. O eşikten sonra ben trunk-based’e geçiyorum: branch’ler saatlerle ölçülür, yarım iş feature flag arkasında kodda yaşar.

Üçü de farklı bir tempo için tasarlanmış araçlar. Hangisinin sizi rahat ettireceği, yazdığınız kod ile prod’unuz arasındaki mesafenin kaç saat olmasını istediğinize bağlı.

Karar değişir, doğrudur

Bugünkü ürün şeklinizi 2 yıl sonraki ekibinize dayatmak en pahalı hatalardan. Üç sinyalden biri değiştiğinde — sürüm sayısı çoğaldı, müşteri tipi değişti, deploy frekansı 10’a fırladı — branch stratejisini de yeniden açın. Workflow bir kez seçilen değil, ürün değiştikçe yeniden değerlendirilen bir karardır.

Branch stratejisinin günlük operasyonel yanını — code review, deploy, rollback rutinini — bir bütün hâlinde Production’da Git: Senior Pratik Rehberi yazısında topladım. Bu seçim, o resmin yalnızca giriş kapısı.

Gitflow ile GitHub Flow arasındaki seçim, “hangisi modern” değil “ürün şekliniz hangisini doğal kılıyor” sorusudur. Yanlış cevap, yıllarca her PR’da iki dakika ödenir.

Git workflow’unu ürüne göre seçin; ürünü workflow’a göre değil.