Git Flow: nedir, dallanma modeli ve projelerde kullanımı

Git Flow Nedir?

Git Flow, geliştirme, sürümler ve düzeltmeleri yönetmek için dalların ve birleştirme kurallarının katı bir yapısını tanımlayan bir Git dallanma modelidir. Vincent Driessen, Ocak 2010’da “A successful Git branching model” makalesini yayınladı ve o zamandan beri Git Flow, kurumsal Java ve .NET geliştirmede fiili standart haline geldi. Ana fikir, kodu farklı kararlılık seviyelerine sahip beş dal türüne ayırmaktır.

Atlassian Git Tutorials, 2024’a göre, Git Flow iki kalıcı dala dayanır: main (daha önce master) ve develop. Diğer tüm dallar geçicidir: feature, release, hotfix. Her dal türünün açıkça tanımlanmış bir yaşam döngüsü ve birleştirme kuralları vardır. Mobil geliştirmede Git Flow, düzenli sürüm döngüleri (2–4 hafta) ve birden çok sürüm desteği olan projelerde kullanılır.

Git Flow, entegrasyon için ayrı bir develop dalı gerektirmesiyle basit modellerden (GitHub Flow) ayrılır. Bu, birleştirme sürecine bir adım ekler, ancak tamamlanmamış özelliklerin sürüme hazır koddan ek olarak yalıtılmasını sağlar.

Vincent Driessen ve Git Flow’un Tarihi

2010 yılında, Vincent Driessen “A successful Git branching model” yazısını yayınladı ve bu yazı Git tarihinde en çok alıntı yapılanlar arasına girdi. Model, sabit sürümleri ve paralel sürüm desteği olan bir proje için oluşturuldu. 2020’de Driessen, Git Flow’un modern CI/CD pratikleri için güncelliğini yitirdiğini kabul etti, ancak model uzun sürüm döngüleri ve eski sürümleri destekleme ihtiyacı olan projeler için hala geçerlidir.

# Git Flow’u başlat
git flow init

# Feature dalı oluştur
git flow feature start "add-auth"

# Feature dalını tamamla (develop’a birleştir)
git flow feature finish "add-auth"

# Release oluştur
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main Dalı: Sürüm Kodu ve Etiketleme

Main (daha önce master), dağıtıma hazır sürüm kodunu içeren ana daldır. Main’deki her commit, anlamsal sürümleme formatında etiketlenmiş belirli bir ürün sürümüne karşılık gelmelidir, örn. v1.0.0, v1.1.0. Main’de doğrudan geliştirme yapılmaz — değişiklikler buraya yalnızca release veya hotfix dalları aracılığıyla gelir.

semver.org, 2024’a göre, main’deki etiketler MAJOR.MINOR.PATCH formatını kullanır. MAJOR, uyumsuz API değişiklikleri için artırılır, MINOR geriye dönük uyumlu işlevsellik eklemeleri için, PATCH hata düzeltmeleri için. Git Flow’da, her sürüm tamamlama, main’de bir sürüm etiketiyle otomatik olarak bir commit oluşturur.

Main dalı, üretime dağıtılan tek daldır. Mobil projeler için bu, main’e yapılan bir push’un App Bundle veya IPA derleme hattını ve Google Play / App Store’da yayınlamayı tetiklediği anlamına gelir. GitLab CI/CD ayarlarında main, force-push ve silmeye karşı korunur.

Anlamsal Sürümleme ve Etiketler

Main’deki her commit’e SemVer formatında bir etikhet eşlik eder: vMAJOR.MINOR.PATCH. MAJOR — uyumsuz API değişiklikleri için, MINOR — geriye dönük uyumlu yeni özellikler için, PATCH — hata düzeltmeleri için. Örnek: v2.1.0, hata düzeltmesi olmayan yeni özelliklerle ikinci ana sürüm anlamına gelir. Git Flow’da, etiketler git flow release finish komutuyla bir release veya hotfix tamamlandığında otomatik olarak oluşturulur.

Develop Dalı: Geliştirme Entegrasyon Hattı

Develop, Git Flow’daki ikinci kalıcı daldır ve tamamlanan tüm özellikleri entegre etmek için tasarlanmıştır. Geliştiriciler, kod incelemesi ve CI/CD kontrollerini geçtikten sonra feature dallarını develop’da birleştirir. Develop, mevcut sprint’in uygulanan tüm özelliklerini içeren en son kararlı kod sürümünü içerir.

DataSift Git Flow Guide, 2024’a göre, develop devam eden entegrasyonlar nedeniyle geçici olarak kararsız olabilir. Sorunları önlemek için ekipler Sürekli Entegrasyon (CI) uygular: her özellik, develop’da birleştirilmeden önce tam bir test paketinden geçmelidir. CI başarısız olursa, geliştirici bir sonraki birleştirmeden önce kodu düzeltir. Develop her zaman main’in mevcut sürümüne bağlıdır: bir sürümden hemen sonra develop, bir birleştirme yoluyla main ile senkronize edilir.

Feature Dalları: Yeni İşlevsellik Geliştirme

Feature dalları, bireysel özellikler, hata düzeltmeleri veya deneyler geliştirmek için geçici dallardır. Her feature dalı develop’dan oluşturulur ve tamamlandıktan sonra develop’a geri birleştirilir. Feature dalının adı genellikle görev numarasını veya kısa bir açıklamayı içerir: feature/APP-123-add-oauth, feature/redesign-profile. Git Flow’da feature dalları sınırsız süreyle var olabilir.

Pro Git Book, 2024’a göre, feature dalları izole bir geliştirme ortamıdır: bir daldaki değişiklikler birleştirmeye kadar diğerlerini etkilemez. Mobil projelerde, feature dalları tamamlama sırasında büyük çakışmaları önlemek için rebase veya merge yoluyla develop ile senkronize edilir. MR oluşturmadan önce feature dalını develop’a rebase etmek önerilir.

# Manuel feature dalı oluşturma (git flow olmadan)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# CLI üzerinden GitLab’da MR oluştur
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release Dalları: Sürüm Hazırlama

Release dalları, bir sürüm hazırlamak için develop’dan oluşturulan geçici dallardır. Develop yeni bir sürüm için yeterli özelliğe sahip olduğunda, ekip release/X.Y.Z dalını oluşturur (örn. release/2.1.0). Bu dalda yalnızca son değişiklikler yapılır: sürüm yükseltmesi, yerelleştirme güncellemesi, son testler, kritik hata düzeltmeleri.

Atlassian Git Tutorials, 2024’a göre, release dalı önemli bir sorunu çözer: son değişiklikleri paralel geliştirmeden ayırmak. Sürüm hazırlanırken, sonraki sürüm için yeni özellikler develop’da birleştirilmeye devam eder. Tamamlandıktan sonra, release dalı main’e (etikhetle birlikte) ve develop’a (sürüm yükseltmesini senkronize etmek için) birleştirilir.

Hotfix Dalları: Üretimde Acil Düzeltmeler

Hotfix dalları, üretimdeki kritik hataları acilen düzeltmek için geçici dallardır. Git Flow’da develop yerine main’den oluşturulan tek dal türüdür. İsim formatı: hotfix/X.Y.Z+1 (örn. hotfix/2.1.1). Tamamlandıktan sonra, hotfix dalı aynı anda main’e (yeni bir yama sürümü olarak) ve develop’a (düzeltmenin gelecek sürümlerde kaybolmaması için) birleştirilir.

DataSift Git Flow Guide, 2024’a göre, hotfix dalları mümkün olduğunca kısa olmalıdır — yalnızca düzeltme ve test. Bir hotfix, yeni özellikler veya yeniden düzenleme içermemelidir. Mobil geliştirmede, hotfix kritik çökmeler (çökme oranı > %0,1), güvenlik açıkları veya App Store’da engelleyen hatalar için kullanılır.

Mobil Geliştirme İçin Git Flow’un Artıları ve Eksileri

Git Flow, özellikle büyük ekipler ve düzenli sürümleri olan projeler için yararlı olan net bir yapı sağlar. Artılar: feature dallarında tamamlanmamış özelliklerin yalıtılması, geliştirmeyi engellemeden sürüm hazırlama imkanı, hotfix aracılığıyla birden çok sürüm desteği. Eksiler: yeni başlayanlar için karmaşıklık, düzenli feature dalı rebase ihtiyacı, uzun ömürlü dallarda çakışmalar.

Martin Fowler, 2024’a göre, Git Flow’un ana dezavantajı uzun ömürlü feature dallarıdır. Bir özellik develop ile senkronize edilmeden 2+ hafta geliştirilirse, birleştirme çakışması önemli hale gelir. Mobil projeler için, feature dalının günlük olarak develop üzerinde rebase ile senkronize edilmesi önerilir.

Git Flow, Sürekli Dağıtım (main’deki her commit → üretim) olan projeler için önerilmez. Bu tür projeler için GitHub Flow veya Trunk-Based Development daha basit ve hızlı bir model sunar. Ancak sürüm döngüleri ve eski sürüm desteği olan projeler için Git Flow en uygun seçim olmaya devam etmektedir.

Git Flow’un Ekip İçin Zararlı Olduğu Durumlar

Git Flow üç durumda sorun haline gelir: 5 kişiden küçük ekipler (gereksiz karmaşıklık), Sürekli Dağıtım (teslimatta gecikme), rebase disiplini eksikliği (uzun ömürlü feature dalları birleştirme çakışmaları yaratır). Bir ekip, dalları birleştirme ve çakışmaları çözme için zamanın %20’sinden fazlasını harcıyorsa — Git Flow bu ekip için uygun değildir, ne kadar büyük olursa olsun.

Git Flow Alternatifleri: GitHub Flow ve Trunk-Based Development

Git Flow alternatifleri, CI/CD uygulayan ekipler için daha basit bir süreç sunar. GitHub Flow yalnızca bir kalıcı dal (main) ve feature dalları kullanır. Her özellik main’den oluşturulur, inceleme ve CI’dan sonra main’e geri birleştirilir ve hemen dağıtılır. GitHub Flow daha basittir ancak tamamlanmamış özelliklerin yalıtılmasını veya paralel sürüm hazırlığını desteklemez.

GitHub Docs, 2024’a göre, Trunk-Based Development (TBD) daha da ileri gider: tüm geliştiriciler tek bir dalda (trunk) çalışır, 1–2 günlük kısa ömürlü feature dalları kullanır. Feature toggles, tamamlanmamış kodun görünürlüğünü kontrol eder. TBD, yüksek CI/CD disiplini ve test otomasyonu gerektirir.

• GitHub Flow — bir main + feature dalları, CI/CD ve küçük ekipler için ideal
• GitLab Flow — Git Flow’u ortam dallarıyla (staging, production) genişletir
• Trunk-Based Development — tek dal + feature toggles, maksimum CI/CD, minimum birleştirme
• One Flow — develop dalı olmadan basitleştirilmiş Git Flow, yalnızca main + feature + release