Git Branch Stratejileri: GitFlow, Trunk-Based ve GitHub Flow

Git Branch Stratejilerine Giriş

Yazılım geliştirme süreçlerinde ekiplerin en kritik kararlarından biri, hangi branch (dal) stratejisini kullanacaklarıdır. Doğru strateji; kod kalitesini artırır, deployment süreçlerini hızlandırır ve ekip içi çatışmaları minimize eder. Bu yazıda en popüler üç stratejiyi — GitFlow, Trunk-Based Development ve GitHub Flow — derinlemesine inceleyeceğiz.

1. GitFlow

GitFlow, 2010 yılında Vincent Driessen tarafından önerilen ve özellikle sürüm tabanlı (release-based) projelerde yaygın olarak kullanılan bir branching modelidir. Uzun ömürlü branch'ler üzerine kuruludur.

Branch Yapısı

• main (master): Her zaman production-ready kodu barındırır. Doğrudan commit yapılmaz.
• develop: Bir sonraki sürüm için geliştirmelerin toplandığı ana geliştirme dalı.
• feature/*: Yeni özellikler için develop'tan açılır, develop'a merge edilir.
• release/*: Sürüm hazırlığı için develop'tan açılır, hem main hem develop'a merge edilir.
• hotfix/*: Production'daki acil hatalar için main'den açılır, hem main hem develop'a merge edilir.

Tipik GitFlow İş Akışı

Bir feature geliştirmek için aşağıdaki adımlar izlenir:

# Yeni feature branch oluştur
git checkout develop
git checkout -b feature/kullanici-profili

# Geliştirme tamamlandıktan sonra
git checkout develop
git merge --no-ff feature/kullanici-profili
git branch -d feature/kullanici-profili

# Release hazırlığı
git checkout -b release/1.2.0 develop

# Release tamamlandığında
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Versiyon 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

GitFlow Ne Zaman Uygundur?

• Belirli sürüm döngüleri olan projeler (örneğin mobil uygulamalar)
• Aynı anda birden fazla sürümün desteklenmesi gereken yazılımlar
• Büyük ekiplerde paralel geliştirme yapılması gerektiğinde
• Sıkı QA ve onay süreçleri olan kurumsal ortamlar

Dezavantajı: Branch sayısı hızla artar, merge conflict riski yükselir ve CI/CD pipeline'ları karmaşıklaşabilir. Küçük ekipler için gereksiz yere ağır bir modeldir.

2. Trunk-Based Development (TBD)

Trunk-Based Development, tüm geliştiricilerin tek bir ana dal (trunk/main) üzerinde çalıştığı veya çok kısa ömürlü branch'ler kullandığı minimalist bir yaklaşımdır. Google, Facebook ve Netflix gibi şirketlerin tercih ettiği bu model, Continuous Integration felsefesinin temelini oluşturur.

Temel Prensipler

• Branch'ler en fazla 1-2 gün yaşar, ardından trunk'a merge edilir.
• Herkes günde en az bir kez trunk'a entegre olur.
• Tamamlanmamış özellikler feature flag'ler ile gizlenir.
• Trunk her zaman deploy edilebilir durumda tutulur.

Feature Flag Kullanımı

Trunk-Based Development'ın en önemli enabler'ı feature flag'lerdir. Yarım kalan bir özelliği production'a göndermek riskli görünse de, flag arkasına alındığında güvenlidir:

# Feature flag ile kontrol
if feature_enabled("yeni_odeme_sistemi"):
    process_payment_v2(order)
else:
    process_payment_v1(order)

Bu yaklaşım sayesinde kod sürekli olarak trunk'a entegre edilir, merge conflict'ler minimuma iner ve integration hell denilen durumdan kaçınılır.

TBD İş Akışı

# Kısa ömürlü branch aç
git checkout main
git checkout -b feat/sepet-guncelle

# Küçük, atomik commit'ler yap
git add -A && git commit -m "Sepet güncelleme endpoint'i eklendi"

# Aynı gün içinde merge et
git checkout main
git pull origin main
git merge feat/sepet-guncelle
git push origin main
git branch -d feat/sepet-guncelle

TBD Ne Zaman Uygundur?

• Sürekli deployment yapan ekipler (günde birden fazla deploy)
• Güçlü otomatik test altyapısı olan projeler
• Deneyimli ve disiplinli geliştirici ekipleri
• Mikroservis mimarilerinde her servisin bağımsız deploy edildiği ortamlar

Dezavantajı: Güçlü bir CI/CD pipeline'ı ve kapsamlı test coverage'ı gerektirir. Feature flag yönetimi zamanla karmaşıklaşabilir. Junior geliştiricilerin doğrudan trunk'a push etmesi riskli olabilir.

3. GitHub Flow

GitHub Flow, GitFlow'un karmaşıklığını ortadan kaldıran ve Pull Request (PR) tabanlı bir iş akışı sunan hafif bir modeldir. Adından da anlaşılacağı gibi GitHub tarafından popülerleştirilmiştir ve özellikle web uygulamaları ile SaaS projelerde yaygın olarak tercih edilir.

Temel Kurallar

1. main branch her zaman deploy edilebilir durumdadır.
2. Yeni bir iş için main'den açıklayıcı isimli bir branch açılır.
3. Bu branch'e düzenli olarak commit ve push yapılır.
4. Geri bildirim veya merge için bir Pull Request açılır.
5. PR onaylandıktan ve testler geçtikten sonra main'e merge edilir.
6. Merge sonrası hemen production'a deploy edilir.

GitHub Flow İş Akışı

# main'den yeni branch
git checkout main
git pull origin main
git checkout -b fix/login-timeout-hatasi

# Geliştirme ve commit'ler
git add src/auth/login.js
git commit -m "Login timeout süresini 30 saniyeye çıkar"
git push origin fix/login-timeout-hatasi

# GitHub üzerinden Pull Request aç
gh pr create --title "Login timeout hatası düzeltmesi" \
  --body "Login sayfasında 5 saniye sonra timeout oluşuyordu.
Timeout süresini 30 saniyeye çıkardım."

# Code review ve onay sonrası merge (genellikle GitHub UI üzerinden)
# Deploy otomatik olarak tetiklenir

GitHub Flow Ne Zaman Uygundur?

• Sürekli deploy edilen web uygulamaları ve SaaS projeleri
• Küçük ve orta ölçekli ekipler
• Açık kaynak projeler (PR tabanlı katkı modeli)
• Tek bir aktif sürümün yeterli olduğu projeler

Dezavantajı: Birden fazla sürümün paralel olarak desteklenmesi gereken projelerde yetersiz kalır. Release ve hotfix için özel bir mekanizma tanımlamaz.

Karşılaştırma Tablosu

• Karmaşıklık: GitFlow (Yüksek) → GitHub Flow (Düşük) → Trunk-Based (En düşük)
• Deploy Sıklığı: GitFlow (Haftalık/aylık) → GitHub Flow (Günlük) → Trunk-Based (Günde birden fazla)
• Branch Ömrü: GitFlow (Günler-haftalar) → GitHub Flow (Saatler-günler) → Trunk-Based (Saatler)
• Code Review: GitFlow (Merge sırasında) → GitHub Flow (PR ile zorunlu) → Trunk-Based (Pair programming veya post-commit)
• Ekip Boyutu: GitFlow (Büyük ekipler) → GitHub Flow (Küçük-orta) → Trunk-Based (Her boyutta, ama disiplin gerektirir)

Hangi Stratejiyi Seçmeliyiz?

Strateji seçimi projenizin doğasına, ekip büyüklüğüne ve deployment modelinize bağlıdır:

• Mobil uygulama veya paketlenmiş yazılım geliştiriyorsanız ve belirli sürüm döngüleriniz varsa → GitFlow
• Web uygulaması veya SaaS geliştiriyorsanız ve düzenli deploy yapıyorsanız → GitHub Flow
• Güçlü CI/CD altyapınız varsa ve günde birden fazla deploy hedefliyorsanız → Trunk-Based Development

Unutmayın: hiçbir strateji mutlak doğru değildir. Ekibinizin olgunluğu, mevcut altyapınız ve proje gereksinimleriniz doğrultusunda hibrit yaklaşımlar da benimseyebilirsiniz. Örneğin, GitHub Flow kullanırken release branch'leri eklemek veya Trunk-Based Development'a kısa ömürlü feature branch'leri dahil etmek oldukça yaygın pratiklerdir.

Sonuç

Branch stratejiniz, yazılım geliştirme sürecinizin temel taşlarından biridir. Doğru stratejiyi seçmek ve ekip genelinde tutarlı bir şekilde uygulamak, merge conflict'leri azaltır, deployment süreçlerini hızlandırır ve kod kalitesini artırır. Önemli olan, seçtiğiniz stratejinin ekibinizin ihtiyaçlarına uygun olması ve herkes tarafından anlaşılıp benimsenmesidir.