Branch Stratejileri
Giriş: Neden Bir Stratejiye İhtiyacımız Var?
Branch oluşturmayı, merge etmeyi ve conflict çözmeyi öğrendin. Artık teknik becerilerin var. Ama şu soru cevapsız: Hangi branch'i ne zaman açmalı? Hangi branch'e merge etmeliyiz? Release nasıl yönetilmeli?
Teknik beceri yetmez — bir strateji lazım. Tıpkı trafik kuralları gibi: herkes araba kullanmayı bilir ama kurallar olmadan kaos çıkar. Branch stratejisi, ekibin "kimin nereye gideceğini" belirleyen trafik kuralları.
Üç büyük strateji var, her biri farklı ekip yapıları ve proje türleri için uygun. Hepsini öğrenip kendi durumuna uygun olanı seçeceksin.
🎬 Analoji: Otoyol Sistemi
Branch stratejilerini şehir yol planlaması gibi düşün:
Git Flow = Büyük şehir otoyol sistemi. Ana yol, yan yollar, servis yolları, otoyol rampları. Karmaşık ama büyük trafiği yönetir.
GitHub Flow = Tek şeritli köy yolu + ara park yerleri. Basit, hızlı, küçük topluluklar için yeterli.
Trunk-Based = Tek bir otoyol, herkes aynı şeritte. Çok disiplinli sürücüler gerektirir ama en hızlı akış.
1. Git Flow
Tarihçe
2010'da Vincent Driessen tarafından önerilen model. Yazılım geliştirmede en çok bilinen branch stratejisi. Özellikle zamanlanmış release'ler yapan ekipler için tasarlandı.
Branch Yapısı
Git Flow'da 5 tür branch var:
Branch Türleri:
1. main (master) → Production'daki kod. Her zaman deploy edilebilir.
2. develop → Geliştirme branch'i. Bir sonraki release'in hazırlandığı yer.
3. feature/* → Yeni özellikler. develop'tan açılır, develop'a merge edilir.
4. release/* → Release hazırlığı. develop'tan açılır, main + develop'a merge edilir.
5. hotfix/* → Acil düzeltmeler. main'den açılır, main + develop'a merge edilir.Görsel Akış
main: ●──────────────────●─────────────────●──────────●──►
│ ▲ ▲ ▲
│ │ release/1.0 │ │ hotfix
│ │ merge │ │ merge
▼ │ │ │
develop: ●──●──●──●──●──●──●──●──●──●──●──●──●──●──●──●──●──►
│ ▲ │ ▲ │ ▲
│ │ │ │ │ │
▼ │ ▼ │ ▼ │
feature/A: ●──●──┘ ●──●──┘ ●──●──┘
login payment search
release: ●──●──● (bug fix only)
▲ │
│ ▼
develop main + develop
hotfix: ●──● (acil fix)
▲ │
│ ▼
main main + developDetaylı Akış
Feature Geliştirme:
# 1. develop'tan feature branch aç
$ git switch develop
$ git pull origin develop
$ git switch -c feature/user-profile
# 2. Geliştirme yap
$ # ... kodla, test et ...
$ git add . && git commit -m "feat: Profil sayfası eklendi"
$ git add . && git commit -m "feat: Profil düzenleme eklendi"
# 3. develop'a merge et
$ git switch develop
$ git merge --no-ff feature/user-profile
$ git push origin develop
# 4. Feature branch'i sil
$ git branch -d feature/user-profileRelease Hazırlığı:
# 1. develop'tan release branch aç
$ git switch develop
$ git switch -c release/1.0.0
# 2. Sadece bug fix ve versiyon güncelleme
$ echo "1.0.0" > VERSION
$ git add . && git commit -m "chore: Version 1.0.0"
# 3. main'e merge et + tag ekle
$ git switch main
$ git merge --no-ff release/1.0.0
$ git tag -a v1.0.0 -m "Version 1.0.0"
$ git push origin main --tags
# 4. develop'a da merge et (fix'ler develop'a da gitsin)
$ git switch develop
$ git merge --no-ff release/1.0.0
$ git push origin develop
# 5. Release branch'i sil
$ git branch -d release/1.0.0Hotfix:
# 1. main'den hotfix branch aç
$ git switch main
$ git switch -c hotfix/critical-bug
# 2. Acil düzeltme
$ # ... fix ...
$ git add . && git commit -m "fix: Kritik güvenlik açığı kapatıldı"
# 3. main'e merge et + tag ekle
$ git switch main
$ git merge --no-ff hotfix/critical-bug
$ git tag -a v1.0.1 -m "Hotfix 1.0.1"
$ git push origin main --tags
# 4. develop'a da merge et
$ git switch develop
$ git merge --no-ff hotfix/critical-bug
$ git push origin develop
# 5. Hotfix branch'i sil
$ git branch -d hotfix/critical-bugGit Flow Ne Zaman Kullanılır?
✅ İyi olduğu durumlar:
- Zamanlanmış release'ler (her 2 haftada, ayda bir)
- Birden fazla production versiyonu destekleniyorsa
- Büyük ekipler (10+ geliştirici)
- Enterprise yazılım, mobil uygulamalar
❌ Uygun olmadığı durumlar:
- Continuous deployment yapan ekipler
- Küçük ekipler (1-3 kişi)
- Web uygulamaları (sürekli deploy)
- Startup'lar (hız öncelikli)⚠️ Dikkat: Git Flow, birçok modern ekip tarafından "fazla karmaşık" bulunur. Vincent Driessen bile 2020'de blog yazısına ekleme yaparak "eğer continuous delivery yapıyorsanız GitHub Flow daha uygun" demiştir. Git Flow'u körü körüne kullanma — projenin ihtiyacına göre karar ver.
2. GitHub Flow
Felsefe
GitHub Flow, Git Flow'un karmaşıklığına bir tepki olarak doğdu. Mantığı çok basit: main her zaman deploy edilebilir, her şey feature branch'inde yapılır, merge Pull Request ile olur.
Branch Yapısı
Sadece 2 tür branch:
1. main → Her zaman production'a deploy edilebilir
2. feature → Her türlü değişiklik (feature, bugfix, docs...) burada yapılırGörsel Akış
main: ●───●───●───────●───────●───●───●───►
│ ▲ │ ▲ │ ▲
│ │ PR │ │ │ │ PR
▼ │merge ▼ │ ▼ │merge
feature: ●───● ●───●───● ●───●
login payment fix6 Adımlık Süreç
┌──────────────────────────────────────────────────┐
│ GITHUB FLOW │
│ │
│ 1. main'den branch aç │
│ $ git switch -c feature/new-thing │
│ │
│ 2. Geliştir, commit at │
│ $ git add . && git commit -m "feat: ..." │
│ │
│ 3. Push et │
│ $ git push origin feature/new-thing │
│ │
│ 4. Pull Request aç (GitHub'da) │
│ → Code review iste │
│ → CI/CD testlerini bekle │
│ │
│ 5. Review + onay sonrası merge et │
│ → GitHub'da "Merge" butonuna tıkla │
│ │
│ 6. Deploy et │
│ → main'e merge = otomatik deploy │
│ │
└──────────────────────────────────────────────────┘Pratik Uygulama
# 1. main'den branch aç
$ git switch main
$ git pull origin main # Güncel ol
$ git switch -c feature/dark-mode
# 2. Geliştir
$ echo ".dark { background: #1a1a2e; }" >> style.css
$ git add . && git commit -m "feat: Dark mode CSS eklendi"
$ echo "toggleDarkMode();" >> app.js
$ git add . && git commit -m "feat: Dark mode toggle fonksiyonu"
# 3. Push et
$ git push -u origin feature/dark-mode
# 4. GitHub'da Pull Request aç
# → Browser'da: "Compare & pull request" butonuna tıkla
# → Başlık: "feat: Dark mode eklendi"
# → Açıklama: Ne yaptığını, neden yaptığını yaz
# → Reviewer ata
# 5. Review sonrası merge (GitHub'da)
# → "Squash and merge" veya "Create a merge commit"
# 6. Yerel temizlik
$ git switch main
$ git pull origin main
$ git branch -d feature/dark-modeGitHub Flow Ne Zaman Kullanılır?
✅ İyi olduğu durumlar:
- Continuous deployment (her merge = deploy)
- Web uygulamaları
- Küçük-orta ekipler (2-15 kişi)
- Hızlı iterasyon gereken projeler
- Open source projeler
❌ Uygun olmadığı durumlar:
- Birden fazla production versiyonu gerektiğinde
- Çok uzun release döngüleri olan projeler
- Strict versioning gereken yazılımlar (kütüphaneler, SDK'lar)💡 İpucu: GitHub Flow'un gücü basitliğinde. Eğer ekibin küçükse veya web projesi geliştiriyorsan, Git Flow'un karmaşıklığına gerek yok. GitHub Flow ile başla, ihtiyaç olursa karmaşıklaştır.
3. Trunk-Based Development
Felsefe
En radikal yaklaşım: herkes doğrudan `main`'e (trunk) commit atar veya çok kısa ömürlü branch'ler kullanır. Branch'ler 1-2 günden fazla yaşamaz.
Bu strateji Google, Meta, Netflix gibi şirketlerde kullanılır. Büyük ölçekte çalışması için güçlü CI/CD ve test altyapısı gerektirir.
Branch Yapısı
main (trunk) = TEK BRANCH. Herkes buraya commit atar.
Kısa ömürlü branch'ler (opsiyonel):
- Max 1-2 gün
- Küçük değişiklikler
- Hızla merge edilirGörsel Akış
main: ●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─►
│ ▲ │ ▲ │ ▲ │ ▲
▼ │ ▼ │ ▼ │ ▼ │
●─┘ ●─┘ ●─┘ ●─┘
(kısa branch'ler — max 1-2 gün)
Veya doğrudan main'e commit:
main: ●─●─●─●─●─●─●─●─●─●─►
Ali Ayşe Ali Mehmet Ali ...Feature Flags ile Çalışma
Trunk-Based Development'ta yarım kalan özellikler nasıl yönetilir? Feature flags ile:
// Özellik henüz hazır değil ama main'de
if (featureFlags.darkMode) {
enableDarkMode();
}
// Production'da flag kapalı → kullanıcı görmez
// Geliştirme/test'te flag açık → test edilebilir# Trunk-Based workflow
$ git switch main
$ git pull origin main
# Küçük, atomik değişiklik yap
$ # ... değişiklik ...
$ git add . && git commit -m "feat: Dark mode toggle (feature flag arkasında)"
$ git push origin main
# CI/CD otomatik test eder ve deploy ederTrunk-Based Ne Zaman Kullanılır?
✅ İyi olduğu durumlar:
- Güçlü CI/CD altyapısı var
- Kapsamlı otomatik test suite
- Deneyimli geliştirici ekibi
- Continuous deployment
- Büyük şirketler (Google, Meta tarzı)
❌ Uygun olmadığı durumlar:
- Yeterli test coverage yoksa
- CI/CD altyapısı zayıfsa
- Junior ağırlıklı ekipler
- Open source projeler (code review süreci gerekli)Strateji Karşılaştırması
┌────────────────────┬──────────────┬──────────────┬──────────────────┐
│ │ Git Flow │ GitHub Flow │ Trunk-Based │
├────────────────────┼──────────────┼──────────────┼──────────────────┤
│ Karmaşıklık │ 🔴 Yüksek │ 🟢 Düşük │ 🟡 Orta │
│ Branch sayısı │ 5 tür │ 2 tür │ 1 (+ kısa) │
│ Release döngüsü │ Zamanlanmış │ Sürekli │ Sürekli │
│ CI/CD gereksinimi │ 🟡 Orta │ 🟡 Orta │ 🔴 Yüksek │
│ Ekip büyüklüğü │ Büyük │ Küçük-Orta │ Her boyut │
│ Öğrenme eğrisi │ 🔴 Dik │ 🟢 Düz │ 🟡 Orta │
│ Code review │ Opsiyonel │ Zorunlu (PR) │ Zorunlu (kısa) │
│ main durumu │ Release'ler │ Her zaman │ Her zaman │
│ │ │ deployable │ deployable │
│ Hotfix │ Ayrı branch │ Feature gibi │ Doğrudan main │
│ Kullananlar │ Enterprise │ Startup, │ Google, Meta │
│ │ │ Open Source │ Netflix │
└────────────────────┴──────────────┴──────────────┴──────────────────┘Hangi Stratejiyi Seçmeliyim?
Karar Ağacı
Projen nasıl deploy ediliyor?
│
├── Zamanlanmış release'ler (ayda bir, 2 haftada bir)
│ └── Birden fazla production versiyonu var mı?
│ ├── EVET → Git Flow
│ └── HAYIR → Git Flow (simplified) veya GitHub Flow
│
├── Continuous deployment (her push = deploy)
│ └── Ekibin büyüklüğü?
│ ├── 1-15 kişi → GitHub Flow
│ └── 15+ kişi → Trunk-Based (+ feature flags)
│
└── Emin değilim
└── GitHub Flow ile başla. İhtiyaç olursa karmaşıklaştır.Pratik Öneriler
Yeni başlıyorsan: GitHub Flow. Basit, anlaşılır, her yerde çalışır.
Freelancer / Solo geliştirici: GitHub Flow (hatta sadece main + feature branch'ler).
Startup: GitHub Flow. Hız öncelikli, karmaşıklık düşmanın.
Orta ölçekli şirket: GitHub Flow veya simplified Git Flow (develop branch'i olmadan).
Enterprise: Git Flow veya Trunk-Based (CI/CD olgunluğuna göre).
Open Source: GitHub Flow (PR tabanlı katkı zorunlu).
💡 İpucu: Strateji seçiminde en kritik soru: "main branch'im her an deploy edilebilir mi?" Eğer evet ise GitHub Flow veya Trunk-Based. Eğer hayır ise Git Flow düşün.
Gerçek Dünya Örnekleri
GitHub (GitHub Flow kullanır)
main ●───●───●───●───●───●───►
│ ▲
▼ │ PR merge + auto deploy
●───●───● featureHer merge production'a gider. Günde onlarca deploy.
Linux Kernel (Hiyerarşik model)
Linus'un main'i ●───●───●───●───►
▲ ▲
│ │
Subsystem maintainer ●───● ●───●
▲ ▲
│ │
Developer ●───● ●En katmanlı model. Her katmanda code review.
Google (Trunk-Based)
main: ●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─►
25,000+ commits/gün, monorepo
Feature flags ile özellik yönetimiTüm Google tek bir repo, tek bir branch. Devasa CI/CD altyapısı.
GitLab Flow — Ortada Bir Yol
GitHub Flow ve Git Flow arasında kalan GitLab Flow, üretim ortamlarını branch'lerle eşleştirir:
GitLab Flow (Environment Branches):
main ●───●───●───●───●───●───► (development)
│ │
pre-production ●───●───● │ (staging/QA)
│ │
production ●───● (production)
Feature → main → pre-production → production
Her merge bir deploy tetikler.GitLab Flow ne zaman?
Birden fazla ortam (staging, production) varsa
GitHub Flow yeterli değilse ama Git Flow fazlaysa
CD pipeline ortam bazlı çalışıyorsa
Release Branch'leri ve Versiyonlama
Git Flow ve benzeri stratejilerde release yönetimi:
Semantic Versioning (SemVer)
v MAJOR.MINOR.PATCH
│ │ │
│ │ └── Bug fix (geriye uyumlu)
│ └──────── Yeni özellik (geriye uyumlu)
└────────────── Breaking change (geriye uyumsuz)
Örnekler:
1.0.0 → İlk kararlı sürüm
1.1.0 → Yeni özellik eklendi
1.1.1 → Bug fix
2.0.0 → API değişti (breaking change)Tag ile Release
# Release tag'i oluştur
$ git tag -a v1.0.0 -m "Version 1.0.0 - İlk kararlı sürüm"
$ git push origin v1.0.0
# Tüm tag'leri listele
$ git tag
v0.1.0
v0.2.0
v1.0.0
# Tag'ler arası değişiklikleri gör
$ git log v0.2.0..v1.0.0 --onelineÖzet
Git Flow: 5 branch türü (main, develop, feature, release, hotfix) — zamanlanmış release'ler için ideal, karmaşık ama kapsamlı
GitHub Flow: 2 branch türü (main, feature) — basit, hızlı, continuous deployment için ideal, PR tabanlı
Trunk-Based Development: Tek branch + kısa ömürlü dallar — en hızlı akış, güçlü CI/CD ve feature flags gerektirir
Strateji seçiminde ekip büyüklüğü, deploy sıklığı ve CI/CD olgunluğu belirleyici
Semantic Versioning (MAJOR.MINOR.PATCH) ile sürümleri yönet
Şüpheye düştüğünde GitHub Flow ile başla — basitlikten karmaşıklığa gitmek, tersinden kolaydır
*Tebrikler! Dallanma bölümünü tamamladın. Bir sonraki bölümde uzak repositoryler — remote, origin, push, pull, clone, fork — dünyasına gireceğiz. Git'i internete bağlama zamanı!*
AI Asistan
Sorularını yanıtlamaya hazır