📄
Text
·
30 min
Workflow Karşılaştırma
Giriş — Hangi Yolu Seçeceksin?
Bir şehirde yeni bir yol yapılacak. Mühendisler üç farklı plan sunuyor:
Plan A (Git Flow): Geniş, çok şeritli otoyol. Her şerit farklı araç tipi için: kamyonlar burada, otobüsler şurada, otomobiller burada. Çok düzenli ama karmaşık — şerit değiştirmek zor, inşası uzun sürüyor.
Plan B (GitHub Flow): Tek bir ana yol, ihtiyaç oldukça yan yollar açılıyor. Basit, hızlı, herkes kolayca kullanabiliyor. Ama çok yoğun trafikte sıkışabilir.
Plan C (Trunk-Based): Çok geniş tek bir ana yol, herkes aynı yolda gidiyor. Yan yollar çok kısa, hemen ana yola geri dönüyor. En hızlı akış ama disiplin gerektirir.
Git dünyasında da "hangi branch stratejisini kullanalım?" sorusu ekiplerin en sık tartıştığı konulardan biri. Doğru cevap "herkese uyan tek bir strateji yok" — ama yanlış cevaplar var. 10 kişilik startup'a Git Flow kadar ağır bir strateji uygulamak veya 200 kişilik bankacılık ekibine "her şeyi main'e push edin" demek felaket olur.
Bu derste üç büyük branching stratejisini derinlemesine karşılaştıracak, gerçek şirketlerin ne kullandığını görecek ve kendi ekibin için doğru stratejiyi seçmeyi öğreneceksin.
Git Flow — Yapısal ve Seremonyal
Tarihçe
Git Flow, 2010 yılında Vincent Driessen tarafından "A successful Git branching model" başlıklı blog yazısıyla tanıtıldı. O dönem için devrimci bir fikirdi — Git'in branching gücünü sistematik bir modele dönüştürüyordu.
Nasıl Çalışır?
Git Flow'da 5 tip branch var:
Uzun Ömürlü (Kalıcı) Branch'ler:
─────────────────────────────────
1. main (master) → Production kodu. Her commit deploy edilmiş versiyon.
2. develop → Geliştirme branch'i. Bir sonraki release'in entegrasyon noktası.
Kısa Ömürlü Branch'ler:
─────────────────────────────────
3. feature/* → Yeni özellikler. develop'tan açılır, develop'a merge edilir.
4. release/* → Release hazırlığı. develop'tan açılır, hem main hem develop'a merge edilir.
5. hotfix/* → Acil düzeltmeler. main'den açılır, hem main hem develop'a merge edilir.Git Flow Diyagramı
main ──●────────────────────●──────────────────●──────●───
│ ↑ ↑ ↑
│ release/1.0 release/1.1│
│ merge ↑ merge │
│ │ ↑ │
│ │ │ hotfix/1.1.1
develop ──●──●──●──●──●──●──●──●──●──●──●──●──●──●──●──●───
↑ ↑ ↑ ↑ ↑ ↑
feature/ feature/ │ feature/ feature/
login payment │ search cart
│
release/1.0
branch açıldıGit Flow Pratikte
# 1. Feature başlat
$ git checkout develop
$ git checkout -b feature/user-dashboard
# ... geliştir, commit at ...
# 2. Feature bitir → develop'a merge
$ git checkout develop
$ git merge --no-ff feature/user-dashboard
$ git branch -d feature/user-dashboard
# 3. Release hazırla
$ git checkout develop
$ git checkout -b release/1.0.0
# ... version bump, son düzeltmeler ...
$ # package.json'da version: "1.0.0"
$ git commit -m "chore: Bump version to 1.0.0"
# 4. Release bitir → main VE develop'a merge
$ git checkout main
$ git merge --no-ff release/1.0.0
$ git tag -a v1.0.0 -m "Version 1.0.0"
$ git checkout develop
$ git merge --no-ff release/1.0.0
$ git branch -d release/1.0.0
# 5. Hotfix (acil düzeltme)
$ git checkout main
$ git checkout -b hotfix/1.0.1
# ... acil fix ...
$ git checkout main
$ git merge --no-ff hotfix/1.0.1
$ git tag -a v1.0.1 -m "Hotfix 1.0.1"
$ git checkout develop
$ git merge --no-ff hotfix/1.0.1
$ git branch -d hotfix/1.0.1Git Flow Avantaj ve Dezavantajları
✅ AVANTAJLAR:
──────────────
• Yapısal ve disiplinli — herkes ne yapacağını bilir
• Release yönetimi güçlü — version bumps, release notes
• Paralel geliştirme kolay — birden fazla feature aynı anda
• Hotfix akışı net — production sorunlarına hızlı müdahale
• Büyük ekiplerde düzen sağlar
❌ DEZAVANTAJLAR:
──────────────────
• Çok karmaşık — 5 branch tipi, çok sayıda merge
• Merge conflict riski yüksek — uzun süren feature branch'ler
• CI/CD ile uyumsuz — sürekli deploy yerine periyodik release
• Bürokratik — branch açmak bile bir prosedür
• Gereksiz overhead — küçük ekipler için fazla ağır
• develop branch'i genelde gereksiz — main yeterliGit Flow Ne Zaman Kullanılır?
✅ Uygun durumlar:
→ Paketlenmiş yazılım (v1.0, v2.0 gibi release'ler)
→ Mobile uygulamalar (App Store review süreci olan)
→ Birden fazla versiyonun aynı anda desteklenmesi gerekiyor
→ Düzenleyici gereksinimler (bankacılık, sağlık)
→ Büyük ekipler (50+ geliştirici)
❌ Uygun olmayan durumlar:
→ Web uygulamaları (sürekli deploy)
→ Küçük ekipler (2-10 kişi)
→ Microservice mimarisi
→ Startuplar (hız öncelikli)GitHub Flow — Basit ve Hızlı
Felsefe
GitHub Flow, GitHub'ın kendi ekibi tarafından kullanılan ve önerilen, son derece basit bir modeldir. Felsefesi: "main her zaman deploy edilebilir durumda olmalı."
Nasıl Çalışır?
Sadece 2 kural:
1. main = her zaman deploy edilebilir
2. Feature branch aç → PR aç → Review → Merge → DeployHepsi bu. develop yok, release branch yok, hotfix branch yok.
GitHub Flow Diyagramı
main ──●──●──●──●──●──●──●──●──●──●──●──●──●──●───
│ ↑ │ ↑ │ ↑ │ ↑
│ │ │ │ │ │ │ │
└─●─●─┘ └─●──┘ └──●──●──┘ └──┘
feature/ fix/ feature/ fix/
login typo dashboard bug-123
(3 commit)(1 commit)(2 commit) (1 commit)GitHub Flow Pratikte
# 1. main'den branch aç (her zaman main'den!)
$ git checkout main
$ git pull origin main
$ git checkout -b feature/add-search
# 2. Geliştir, commit at
$ # ... kod yaz ...
$ git add .
$ git commit -m "feat: Add search component"
$ git commit -m "feat: Add search API integration"
# 3. Push et
$ git push origin feature/add-search
# 4. GitHub'da PR aç
# → Review iste
# → CI pipeline otomatik çalışır
# → Review onayı al
# 5. Merge (squash merge önerilir)
# → GitHub UI'da "Squash and merge"
# → Otomatik deploy tetiklenir
# 6. Branch'i sil
$ git checkout main
$ git pull origin main
$ git branch -d feature/add-searchGitHub Flow Avantaj ve Dezavantajları
✅ AVANTAJLAR:
──────────────
• Çok basit — öğrenmesi kolay, uygulaması kolay
• CI/CD ile mükemmel uyum — her merge deploy olabilir
• Kısa yaşam döngüsü — branch'ler saatler/günler içinde merge
• Hızlı feedback — PR'da review, CI sonuçları hemen
• Sürekli deploy — main'e merge = canlıya çık
❌ DEZAVANTAJLAR:
──────────────────
• Release yönetimi yok — versiyonlama senin sorumluluğun
• Birden fazla versiyon desteklemez — sadece "en son" var
• Büyük projeler için yetersiz kalabilir
• Hotfix ayrımı yok — her şey aynı akışta
• Disiplin gerektirir — main'in her zaman deploy edilebilir
kalması ekibin sorumluluğuGitHub Flow Ne Zaman Kullanılır?
✅ Uygun durumlar:
→ Web uygulamaları (SaaS)
→ Sürekli deploy yapılan projeler
→ Küçük-orta ekipler (2-20 kişi)
→ Microserviceler
→ Startuplar
→ Open source projeler
❌ Uygun olmayan durumlar:
→ Birden fazla version desteklenmesi gereken projeler
→ Düzenleyici gereksinimler olan projeler
→ Uzun release döngüsü olan projeler (mobil)Trunk-Based Development — Cesaret ve Disiplin
Felsefe
Trunk-Based Development (TBD), en agresif branching stratejisidir. Temel fikir: "Herkes doğrudan trunk'a (main) commit atar veya çok kısa ömürlü branch'ler kullanır."
Bu, Git Flow'un tam zıddıdır. Branch'ler saatler içinde merge edilir — günler değil, haftalar hiç değil.
Nasıl Çalışır?
İki varyant var:
Varyant 1: Doğrudan main'e commit (küçük ekipler)
→ Her geliştirici main'e push eder
→ Pair programming veya mob programming ile kalite sağlanır
Varyant 2: Kısa ömürlü branch'ler (büyük ekipler)
→ Branch açılır ama max 1-2 gün yaşar
→ Küçük PR'lar, hızlı review, hemen mergeTrunk-Based Diyagram
Varyant 1 (Doğrudan commit):
main ──●──●──●──●──●──●──●──●──●──●──●──●──●──●──●───
Ali Ayşe Ali Mehmet Ayşe Ali Mehmet Ayşe
Varyant 2 (Kısa branch'ler):
main ──●──●──●──●──●──●──●──●──●──●──●──●──●───
│ ↑ │ ↑ │ ↑ │ ↑
└──┘ └──┘ └──┘ └──┘
Ali Ayşe Mehmet Ali
(2 saat)(3 saat)(4 saat)(1 saat)Feature Flag'ler — TBD'nin Sırrı
"Ama yarım kalmış özelliği main'e nasıl merge ederiz?" — Feature flag'ler ile:
// Feature flag ile yarım özellik güvenle main'de
if (featureFlags.isEnabled('new-dashboard')) {
// Yeni dashboard'u göster
return <NewDashboard />;
} else {
// Eski dashboard'u göster
return <OldDashboard />;
}
// Geliştirme bitince flag'i aç:
// featureFlags.enable('new-dashboard')
// İstenirse kademeli açılabilir:
// %10 kullanıcıya aç → %50 → %100Feature Flag Avantajları:
─────────────────────────
✅ Yarım özellik main'de olabilir (flag kapalıysa kullanıcı görmez)
✅ A/B testing yapabilirsin
✅ Kademeli (canary) rollout mümkün
✅ Sorun olursa flag'i kapat — kod rollback'tan hızlı
✅ Dark launch: özellik hazır ama kimse bilmiyor
Feature Flag Dezavantajları:
─────────────────────────────
❌ Ek karmaşıklık — flag'ler birikince spagetti olur
❌ Temizlenmesi gereken teknik borç oluşturur
❌ Test matrisini büyütür (flag açık + kapalı)Trunk-Based Avantaj ve Dezavantajları
✅ AVANTAJLAR:
──────────────
• Merge conflict neredeyse yok — herkes aynı koda bakıyor
• Sürekli entegrasyon (gerçek anlamda) — CI her zaman çalışıyor
• Çok hızlı feedback döngüsü
• Refactoring kolay — branch'ler arasında senkronizasyon sorunu yok
• Basit Git geçmişi — lineer, okunaklı
• Google, Meta, Netflix gibi şirketlerin tercihi
❌ DEZAVANTAJLAR:
──────────────────
• Çok disiplinli ekip gerektirir
• Feature flag altyapısı gerekir
• Güçlü CI/CD şart — kırılan main = herkes durur
• Deneyimsiz ekiplerde kaos riski
• Code review zorlaşabilir (doğrudan commit varyantında)
• Rollback stratejisi şartTrunk-Based Ne Zaman Kullanılır?
✅ Uygun durumlar:
→ Deneyimli ekipler
→ Microservice mimarisi
→ Güçlü CI/CD altyapısı olan projeler
→ Feature flag sistemi olan projeler
→ Günde birden fazla deploy yapan ekipler
→ Google, Meta, Netflix ölçeğindeki şirketler
❌ Uygun olmayan durumlar:
→ Deneyimsiz ekipler
→ CI/CD altyapısı zayıf projeler
→ Open source projeler (dış katkı akışı farklı)
→ Paketlenmiş yazılım (versiyonlama gerekli)GitLab Flow — Orta Yol
Kısaca değinelim: GitLab Flow, GitHub Flow ile Git Flow arasında bir orta yol sunar.
GitLab Flow: Environment branch'leri ekler
main → staging → production
│
└── feature branch'ler (GitHub Flow gibi)
main'e merge → staging'e otomatik deploy
staging onayı → production'a deployGitLab Flow Ne Zaman?
→ Birden fazla ortamı (staging, production) desteklemen gerektiğinde
→ GitHub Flow çok basit, Git Flow çok karmaşık olduğunda
→ Continuous Delivery (manuel deploy) istediğindeBüyük Karşılaştırma Tablosu
┌─────────────────────┬───────────────┬───────────────┬───────────────┐
│ │ Git Flow │ GitHub Flow │ Trunk-Based │
├─────────────────────┼───────────────┼───────────────┼───────────────┤
│ Karmaşıklık │ 🔴 Yüksek │ 🟢 Düşük │ 🟡 Orta │
│ Branch sayısı │ 5 tip │ 2 (main+feat) │ 1-2 │
│ Branch ömrü │ Günler-haftalar│ Saatler-günler│ Saatler │
│ Release yönetimi │ ✅ Güçlü │ ❌ Yok │ ❌ Yok (flag) │
│ CI/CD uyumu │ 🟡 Orta │ ✅ İyi │ ✅ Mükemmel │
│ Deploy sıklığı │ Haftalık/aylık│ Günlük │ Saatlik/günlük│
│ Merge conflict │ 🔴 Sık │ 🟡 Orta │ 🟢 Nadir │
│ Ekip boyutu │ 20-200+ │ 2-30 │ 5-1000+ │
│ Öğrenme eğrisi │ 🔴 Dik │ 🟢 Düz │ 🟡 Orta │
│ Feature flag gerekir│ ❌ Hayır │ ❌ Hayır │ ✅ Evet │
│ Hotfix akışı │ ✅ Özel branch│ PR (aynı akış)│ PR/commit │
│ Çoklu versiyon │ ✅ Destekler │ ❌ Desteklemez│ ❌ Desteklemez│
│ Otomasyon ihtiyacı │ 🟡 Orta │ 🟡 Orta │ 🔴 Yüksek │
└─────────────────────┴───────────────┴───────────────┴───────────────┘Gerçek Şirketler Ne Kullanıyor?
Google — Trunk-Based (Monorepo)
Google'ın yaklaşımı:
─────────────────────
• 25,000+ geliştirici, TEK monorepo
• Tüm kod tek bir repository'de (milyon+ dosya)
• Doğrudan trunk'a commit
• Çok güçlü CI sistemi (Forge)
• Feature flag'ler yaygın
• Code review HER commit için zorunlu
• Piper (kendi VCS'leri, Git benzeri) kullanıyorlarMeta (Facebook) — Trunk-Based
Meta'nın yaklaşımı:
────────────────────
• Monorepo (Mercurial tabanlı, Git'e geçiş sürecinde)
• Trunk-based development
• Günde binlerce commit
• Gatekeeper (feature flag sistemi)
• Kademeli rollout: %1 → %10 → %50 → %100
• Sorun olursa flag kapatılır (rollback yerine)Netflix — Trunk-Based (Microservices)
Netflix'in yaklaşımı:
──────────────────────
• Yüzlerce microservice, her birinde ayrı repo
• Trunk-based + kısa ömürlü branch'ler
• Günde yüzlerce deploy
• Spinnaker (kendi CD platformları)
• Canary deploy — yeni versiyon %5 trafiğe açılır
• Sorun olursa otomatik rollbackSpotify — Squad-Based (Hibrit)
Spotify'ın yaklaşımı:
──────────────────────
• Squad (küçük ekip) bazlı organizasyon
• Her squad kendi branching stratejisini seçebilir
• Çoğu GitHub Flow benzeri kullanıyor
• Deploy sıklığı squad'a göre değişir
• Trunk-based'e doğru evrilme eğilimiMicrosoft — Karma (Projeye Göre)
Microsoft'un yaklaşımı:
────────────────────────
• Windows: Git Flow benzeri (uzun release döngüsü)
• VS Code: GitHub Flow (günlük release)
• Azure DevOps: Trunk-based
• Office: Git Flow + release branch'leri
• GitHub: GitHub Flow (doğal olarak)
→ Tek şirket, birden fazla strateji — projeye göre değişirStartuplar — Genellikle GitHub Flow
Startup yaklaşımı:
───────────────────
• 2-10 kişilik ekip
• GitHub Flow (veya basitleştirilmiş trunk-based)
• main'e merge = deploy
• Hız öncelikli, formalite minimum
• Büyüdükçe stratejini güncelleStrateji Seçim Rehberi
Karar Ağacı
Proje tipi ne?
│
├── Paketlenmiş yazılım (v1, v2, mobil app)?
│ └── Git Flow (veya basitleştirilmiş versiyon)
│
├── Web SaaS / API?
│ ├── Ekip kaç kişi?
│ │ ├── 2-10 → GitHub Flow
│ │ ├── 10-50 → GitHub Flow veya Trunk-Based
│ │ └── 50+ → Trunk-Based (feature flag ile)
│ │
│ └── Deploy sıklığı?
│ ├── Haftalık/aylık → GitHub Flow
│ ├── Günlük → GitHub Flow veya Trunk-Based
│ └── Saatlik → Trunk-Based
│
├── Open source?
│ └── GitHub Flow (fork + PR)
│
└── Emin değilim
└── GitHub Flow ile başla, gerektiğinde evrilEvrim Yolu
Birçok ekip şu yolu izler:
Git Flow ─────► GitHub Flow ─────► Trunk-Based
(başlangıç) (olgunlaşma) (ileri seviye)
"Her şeyi "Basitleştirelim, "Branch'e bile
kontrol develop gereksiz, gerek yok, direkt
edelim" main yeterli" main'e commit"💡 İpucu: Eğer yeni bir proje başlıyorsan, GitHub Flow ile başla. Basit, etkili ve çoğu durumda yeterli. İhtiyaç büyüdükçe trunk-based'e geçersin. Git Flow'a sadece gerçekten versiyonlu release yapman gerekiyorsa başvur.
Karma (Hibrit) Stratejiler
Gerçek dünyada çoğu ekip saf bir strateji değil, karışım kullanır:
Simplified Git Flow
Git Flow'un basitleştirilmiş hali:
→ develop branch'i YOK
→ main + feature branch + release tag
→ Hotfix = normal PR akışı
main ──●──●──●──●──●──●──●──●──●──●───
│ ↑ │ ↑ │ ↑
└──┘ └─●─●─┘ └──┘
feat/ feat/ fix/
login search bug
↑
v1.0.0 (tag)GitHub Flow + Release Tag
GitHub Flow'a release tag eklenmesi:
→ Normal GitHub Flow akışı
→ Belirli noktalarda versiyon tag'ı at
→ Release notes otomatik oluştur
main ──●──●──●──●──●──●──●──●──●──●───
↑ ↑ ↑
v1.0.0 v1.1.0 v1.2.0Strateji Geçişi — Nasıl Yapılır?
Git Flow'dan GitHub Flow'a Geçiş
# 1. develop'u main ile senkronize et
$ git checkout main
$ git merge develop
# 2. Açık feature branch'leri main'den rebase et
$ git checkout feature/x
$ git rebase main
# 3. develop branch'ini sil
$ git branch -d develop
$ git push origin --delete develop
# 4. Branch protection'ı güncelle
# → main için PR gereksinimi ekle
# → CI check'leri required yap
# 5. Ekiple yeni kuralları paylaş
# → Her şey main'den açılır, main'e merge edilir
# → deploy = main'e mergeGitHub Flow'dan Trunk-Based'e Geçiş
1. Feature flag altyapısı kur (LaunchDarkly, Unleash, vb.)
2. CI pipeline'ı güçlendir (5 dk altında çalışmalı)
3. Branch yaşam süresini kısalt (max 1 gün)
4. PR boyutunu küçült (max 200-300 satır)
5. Pair programming pratik et (code review alternatifi)
6. Kademeli geçiş: kısa branch → daha kısa → direkt commitYaygın Hatalar
1. Ekip Boyutuna Uyumsuz Strateji
❌ 3 kişilik startup → Git Flow
→ Gereksiz bürokrasi, hızı öldürür
❌ 100 kişilik banka → "Herkes main'e push etsin"
→ Kaos, kırılan build'ler, regresyonlar
✅ Ekip boyutu ve projenin ihtiyaçlarına göre seç2. Uzun Yaşayan Feature Branch'ler
❌ feature/new-architecture (3 ay açık kalmış)
→ 500 dosya değişmiş, merge conflict kabus
→ "Merge günü" = 2 gün çalışma
✅ Büyük özellikleri küçük parçalara böl
→ feature/arch-step1 (3 gün) → merge
→ feature/arch-step2 (2 gün) → merge
→ feature/arch-step3 (4 gün) → merge3. Stratejiyi Belgelememek
❌ Ekipte herkes farklı strateji kullanıyor
→ Ali Git Flow yapıyor, Ayşe direkt main'e push ediyor
✅ CONTRIBUTING.md'de stratejiyi belgele:
"Bu projede GitHub Flow kullanılır. Tüm değişiklikler
main'den açılan branch'lerde PR ile merge edilir."Özet
Git Flow yapısal ve seremonyal bir modeldir — 5 branch tipi, release yönetimi güçlü ama karmaşık; paketlenmiş yazılım ve büyük ekipler için uygundur
GitHub Flow basit ve hızlıdır — main + feature branch, her merge deploy olabilir; web uygulamaları ve küçük-orta ekipler için idealdir
Trunk-Based Development en agresif yaklaşımdır — herkes doğrudan main'e commit eder veya çok kısa ömürlü branch'ler kullanır; güçlü CI/CD ve feature flag gerektirir; Google, Meta, Netflix gibi şirketlerin tercihi
Doğru strateji ekip boyutuna, deploy sıklığına, proje tipine ve ekip deneyimine bağlıdır — çoğu ekip için GitHub Flow ile başlayıp gerektiğinde evrilmek en sağlıklı yoldur
Gerçek dünyada çoğu ekip hibrit yaklaşım kullanır — saf bir stratejiye bağlı kalmak yerine, projenin ihtiyaçlarına göre uyarlama yapar
Stratejiyi belgele ve ekiple paylaş — herkesin aynı kurallarla çalışması, hangi stratejiyi kullandığından daha önemlidir
*Bir sonraki ve son dersimizde Git mülakat sorularına ve pratik senaryolara bakacağız — kariyer yolculuğunda Git bilgini kanıtlama zamanı!*
AI Asistan
Sorularını yanıtlamaya hazır