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

Ekipteki herkes farklı branch'larda mı çalışıyor? Merge conflict'ler mi bitmiyor? Doğru branching stratejisi ile ekibinizin verimliliğini artırın ve deploy sürecinizi hızlandırın.

Neden Branching Stratejisi?

Branching stratejisi, ekibin kod üzerinde nasıl paralel çalışacağını ve değişikliklerin nasıl entegre edileceğini tanımlar:

• Merge conflict'leri azaltır
• Deploy sürecini standartlaştırır
• Kod kalitesini artırır
• CI/CD pipeline'ını kolaylaştırır

1. GitFlow

En detaylı ve yapılandırılmış strateji. Vincent Driessen tarafından 2010'da tanıtıldı.

Branch'lar

main ──────────────────────────────────────────→
  └─ develop ──────────────────────────────────→
       ├─ feature/login ──→ merge to develop
       ├─ feature/payment ──→ merge to develop
       └─ release/1.0 ──→ merge to main + develop
          └─ hotfix/bugfix ──→ merge to main + develop

| Branch | Amaç | Ömür | |--------|------|------| | main | Üretim kodu | Kalıcı | | develop | Geliştirme | Kalıcı | | feature/ | Yeni özellik | Geçici | | release/ | Sürüm hazırlığı | Geçici | | hotfix/ | Acil düzeltme | Geçici |

Ne Zaman GitFlow?

• ✅ Uzun sürüm döngüleri (ayda bir)
• ✅ Birden fazla sürümü desteklemek
• ❌ Sürekli deployment yapan ekipler için karmaşık

2. GitHub Flow

Basit ve çevik. main + feature branch'lar:

main ──────────────────────────────────────→
  ├─ feature/login ──PR──→ merge + deploy
  ├─ feature/payment ──PR──→ merge + deploy
  └─ fix/header-bug ──PR──→ merge + deploy

Akış

1. main'den yeni branch oluştur
2. Değişiklikleri commit'le
3. Pull Request (PR) aç
4. Kod inceleme (review)
5. main'e merge et
6. Otomatik deploy

Ne Zaman GitHub Flow?

• ✅ Sürekli deployment
• ✅ Küçük-orta ekipler
• ✅ SaaS ürünleri
• ❌ Çoklu sürüm desteği gerekiyorsa

3. Trunk-Based Development

En minimal yaklaşım. Herkes doğrudan main (trunk) branch'ine çalışır:

main ──────────────────────────────────→
  ├─ (küçük commit)
  ├─ short-lived-branch (max 1 gün) ──→ merge
  ├─ (küçük commit)
  └─ short-lived-branch (max 1 gün) ──→ merge

Kurallar

• Branch ömrü maksimum 1 gün
• Günde birden fazla merge
• Feature flag ile tamamlanmamış özellikler gizlenir
• Güçlü CI/CD pipeline şart

Ne Zaman Trunk-Based?

• ✅ Yüksek frekanslı deployment (günde birkaç kez)
• ✅ Feature flag kullanan ekipler
• ✅ Google, Meta gibi büyük ekipler
• ❌ CI/CD altyapısı zayıfsa

Karşılaştırma

| Özellik | GitFlow | GitHub Flow | Trunk-Based | |---------|---------|-------------|-------------| | Karmaşıklık | Yüksek | Düşük | En düşük | | Deploy sıklığı | Haftalık/aylık | Günlük | Sürekli | | Branch ömrü | Günler/haftalar | Saatler/günler | Saatler | | Feature flag | Opsiyonel | Opsiyonel | Neredeyse zorunlu | | Ekip boyutu | Her boyut | Küçük-orta | Her boyut | | CI/CD gereksinimi | Normal | İyi | Mükemmel |

Commit Konvansiyonları

feat: yeni özellik eklendi
fix: hata düzeltmesi
docs: dokümantasyon güncelleme
refactor: yeniden yapılandırma
test: test ekleme/güncelleme
chore: yapılandırma, bağımlılık
ci: CI/CD değişiklikleri

Semantic Versioning

v1.2.3
 │ │ └─ PATCH: Bug fix
 │ └── MINOR: Yeni özellik (geriye uyumlu)
 └─── MAJOR: Breaking change

Best Practices

1. PR boyutunu küçük tutun — 200-400 satır ideal
2. Kod incelemesi zorunlu — En az 1 reviewer
3. CI her PR'da çalışsın — Testler geçmeden merge yok
4. Branch koruma kuralları — main'e direkt push engellenmeli
5. Squash merge tercih edin — Temiz commit history
6. Branch temizliği — Merge edilen branch'ları silin

Sonuç

Branching stratejisi, ekipinizin boyutuna, deploy sıklığına ve projenin karmaşıklığına göre seçilmeli. Küçük ekipler GitHub Flow, hızlı deploy yapanlar Trunk-Based, karmaşık sürüm yönetimi gerektirenler GitFlow tercih edebilir.

Git ve branching stratejilerini LabLudus platformunda pratik yaparak öğrenin.