Git Branching Stratejileri: Farklı Takımlar ve Ürünler için Gerçek Dünya Dersleri

Git dallanma stratejisi, devam eden işin bir sürüme nasıl dönüşeceğini tanımlar: kimin nereye commit edebileceği, dalların ne zaman birleşeceği ve main dalının her an deploy edilebilir olup olmadığını neyin belirlediği. Stratejiler arasındaki dengeler (trunk-based development, GitHub Flow, Git Flow, release branch’leri) gerçek ve alana özeldir; üç kişilik bir mobil ekip için mükemmel çalışan bir strateji 25 geliştiricide kırılır, 25’e ölçeklenen strateji ise üç kişilik ekibe gereksiz koordinasyon yükü getirir. Çoğu dallanma stratejisi başarısızlığı aslında stratejinin kendisiyle ilgili değildir; ekip büyüklüğünü ya da ürün temposunu aşan bir stratejinin hâlâ uygulanıyor olmasıyla ilgilidir.

Bu yazı, üretimdeki yaygın Git dallanma stratejilerini, bir stratejinin diğerine devredildiği ekip büyüklüğü ve sürüm temposu eşiklerini, çoğu ürün ekibinin yakınsadığı trunk-based development varsayılanlarını ve stratejiler arası geçiş maliyetlerini ele alır.

Ana Branching Stratejileri: Gerçekte Ne İşe Yarıyor

Takım büyüklüğüne göre önerilere geçmeden önce, ana stratejileri ve ne zaman işe yaradıklarını ya da başarısız olduklarını inceleyelim. Her stratejinin güçlü ve zayıf yönleri vardır; doğru seçim takımın büyüklüğüne, ürün tipine ve deployment kültürüne bağlıdır.

Trunk-Based Development: Hız Kralı

Nedir: Herkes direkt main’e (trunk) commit atar, çok kısa yaşayan feature branch’ler (< 2 gün).

Ne zaman mükemmel çalışır:

• Küçük takımlar (2-8 developer)
• Yüksek güven ortamı
• Mükemmel test coverage
• Tamamlanmamış feature’lar için feature flag’ler
• Continuous deployment mindset

Küçük ölçekte trunk-based: 4 kişilik bir startup ekibi trunk-based development ile günde 15 deploy yapar, sıfır merge conflict yaşar ve inanılmaz hızlı hareket eder. Küçük takım büyüklüğü koordinasyon yükünü ihmal edilebilir kılar.

Ne zaman felaket:

• Koordinasyonsuz büyük takımlar
• Yetersiz test coverage
• Karmaşık release süreçleri
• Yeterli disiplin olmadan

Trunk-based, disiplin ve güven gerektirir; bu koşullar yoksa hız yerine kaos üretir.

40 developer çöküşü: 40 kişilik bir ekip “Netflix yapıyor” gerekçesiyle trunk-based geçişi yapar. İki hafta içinde main branch her gün bozulur, geliştiriciler commit atmaktan korkar, üretkenlik dibe vurur. Acil durum Git Flow implementasyonu gerekir. Netflix ölçeğinde disiplin, Netflix ölçeğinde test altyapısı gerektirir.

Git Flow: Enterprise Ağır Sıkleti

Nedir: Main, develop, feature, release ve hotfix branch’leriyle karmaşık branching modeli.

Ne zaman işe yarar:

• Büyük takımlar (50+ developer)
• Programlı release’ler
• Birden fazla environment
• Sıkı kalite kapıları
• Enterprise compliance gereksinimleri

Ne zaman overkill:

• Küçük takımlar
• Continuous deployment
• Basit uygulamalar
• Hız isteyen startup’lar

200 kişilik takımda Git Flow: Geliştirici zamanının %30’u branch management’a gider. Kalite için iyi, hız için berbat. Büyük takımlarda kalite kritikse bu denge kabul edilebilir; startup’larda ise takım hızını öldürür.

GitHub Flow: Dengeli Yaklaşım

Nedir: Main branch ve feature branch’lerle basit flow, pull request’ler üzerinden deploy.

Ne zaman mükemmel:

• Orta takımlar (5-30 developer)
• Continuous deployment
• İyi CI/CD pipeline
• Pull request kültürü

15 kişilik SaaS takımı: GitHub Flow ile günde 3-5 deploy, minimal overhead. Kalite için yeterli süreç, fazla yük değil. Takımların büyük çoğunluğu GitHub Flow ile başlamalı; gerekirse daha sonra Git Flow veya trunk-based’e evrimleşebilir.

GitLab Flow: Environment-Aware Strateji

Nedir: GitHub Flow + farklı deployment aşamaları için environment branch’leri.

Ne zaman kullan:

• Farklı deployment programları gerekiyor
• Karmaşık environment yönetimi (staging’de uzun test dönemleri)
• Düzenlenmiş endüstriler (finans, sağlık)
• Environment başına farklı onay süreçleri

Tag-Based Release Flow: Production-Ready Strateji

Nedir: Main’den feature branch’ler, PR’lar için preview environment’lar, otomatik dev deployment, tag-triggered release’ler staging’den production’a.

Komplet workflow:

1. Feature Development

   git checkout main
   git pull origin main
   git checkout -b feature/payment-integration
   # Development çalışması
   git push origin feature/payment-integration

2. PR ve Preview

   • PR oluştur → Otomatik preview environment (preview-abc123.domain.com)
   • Preview’da code review ve testing
   • main’e merge → Dev environment’a otomatik deploy

3. Release Süreci

   # Tag oluştur ve push et
   git tag -a v1.3.0 -m "Release v1.3.0: Payment integration"
   git push origin v1.3.0
   
   # Bu şunları tetikler:
   # 1. v1.3.0 versiyonuyla build
   # 2. Staging'e deploy
   # 3. Otomatik testleri çalıştır
   # 4. QA takımını bilgilendir

4. QA ve Production

   • QA staging’de test eder (staging.domain.com)
   • CI/CD sisteminde manuel onay
   • Otomatik production deployment
   • Önceki tag ile rollback mevcut

Gerçek implementasyon (GitHub Actions):

# .github/workflows/release.yml
name: Release Pipeline

on:
  push:
    tags:
      - 'v*'

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Versiyon çıkar
        id: version
        run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT

      - name: Staging'e Deploy
        run: |
          docker build -t app:${{ steps.version.outputs.VERSION }} .
          kubectl set image deployment/app app=app:${{ steps.version.outputs.VERSION }} -n staging

      - name: Integration Testleri Çalıştır
        run: npm run test:integration:staging

      - name: QA Takımını Bilgilendir
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {
              "text": "Versiyon ${{ steps.version.outputs.VERSION }} staging'e deploy edildi",
              "staging_url": "https://staging.domain.com"
            }

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Production'a Deploy
        run: |
          kubectl set image deployment/app app=app:${{ steps.version.outputs.VERSION }} -n production

      - name: Deployment Doğrula
        run: kubectl rollout status deployment/app -n production

Bu strateji neden işe yarıyor:

• Net ayrım development ve release süreçleri arasında
• Immutable release’ler - her tag spesifik bir versiyonu temsil eder
• Kolay rollback’ler - sadece önceki tag’i deploy et
• Environment progression - dev → staging → production
• QA gate’leri - production’dan önce manuel onay
• Audit trail - tag’ler versiyon geçmişi sağlar

Gelişmiş versioning stratejisi:

// Semantic versioning otomasyonu
const bumpVersion = (currentVersion, changeType) => {
  const [major, minor, patch] = currentVersion.split('.').map(Number);

  switch(changeType) {
    case 'major': return `${major + 1}.0.0`; // Breaking change'ler
    case 'minor': return `${major}.${minor + 1}.0`; // Yeni feature'lar
    case 'patch': return `${major}.${minor}.${patch + 1}`; // Bug fix'ler
  }
};

// Commit mesajlarına göre
if (commitMessages.includes('BREAKING CHANGE')) {
  newVersion = bumpVersion(currentVersion, 'major');
} else if (commitMessages.includes('feat:')) {
  newVersion = bumpVersion(currentVersion, 'minor');
} else {
  newVersion = bumpVersion(currentVersion, 'patch');
}

Production rollback stratejisi:

# Önceki versiyona acil rollback
git tag -l | grep '^v' | sort -V | tail -2 | head -1
# Önceki tag'i deploy et
kubectl set image deployment/app app=app:v1.2.9 -n production

# Ya da otomatik rollback
if [[ $(curl -s -o /dev/null -w "%{http_code}" https://api.domain.com/health) != "200" ]]; then
  echo "Health check başarısız, rollback yapılıyor..."
  kubectl rollout undo deployment/app -n production
fi

Bu stratejiyi ne zaman kullan:

• Orta/büyük takımlar (10+ developer)
• QA onay gate’lerine ihtiyaç
• Farklı amaçlara sahip birden fazla environment
• Release tracking için compliance gereksinimleri
• Kolay rollback ihtiyacı
• Programlı release’ler (continuous deployment değil)

25 kişilik fintech ekibinde tag-based: Deployment hataları %80 azaldı, QA hangi versiyonu test ettiğini her zaman bildi. Rollback’ler 45 dakikalık oturumlardan 2 dakikalık tag deployment’larına dönüştü.

Yaygın tuzaklar:

• Tag disiplini - developer’lar semantic versioning’i anlamalı
• Environment drift - staging production konfigürasyonuyla match etmeli
• Test data management - staging production-benzeri data’ya ihtiyaç duyar
• Hotfix handling - acil patch’ler için süreç gerekli

Gerçeklik Kontrolü: Takım Büyüklüğü Düşündüğünden Daha Önemli

2-3 Developer Takımları: Basit Tut

3 kişilik bir fintech startup ekibinin deneyimi, bu ölçekte neyin işe yaradığını netleştirir:

Develop branch yok, release branch’ler yok, karmaşık flow yok. 3 kişiyle herkes codebase’in durumunu zaten biliyor; ek branch katmanlarının faydası maliyetini karşılamıyor.

İşe yarayan yapı:

• Main’den direkt feature branch’ler
• Main’e merge = production’a deploy (otomatik)
• Hotfix’ler direkt main’e
• Main’i takip eden tek staging environment

Neden çalışır:

• İletişim overhead’i minimaldır
• Herkes codebase durumunu bilir
• Hızlı feedback loop’lar (günde 5-10 deploy)

Kaçınılacak kritik hata: Bu ölçekte Git Flow implement etmek. 7 farklı branch tipiyle çalışan 4 kişilik ekipler, merge karmaşıklığı yüzünden iki haftada bir deploy’a düşmüştür. Küçük takımlar için basitlik önceliktir; karmaşıklık yalnızca gerçek bir ihtiyaç ortaya çıktığında eklenmeli.

10-20 Developer Takımları: Geçiş Bölgesi

Bu büyüklükte artık herhangi bir kişi codebase’in tam durumunu kafasında tutamaz. Bir SaaS şirketinde 20 developer seviyesi bu kırılma noktasını somut biçimde gösterir.

Kritik eklemeler:

• Integration point olarak develop branch
• Stabilizasyon için release branch’ler
• Branch isimlerinde gerçek ticket numaraları (artık tracking lazım)

Bu ölçekte işe yarayan environment yapısı:

# Environment mapping
environments:
  dev:
    branch: develop
    deploy: her_commit'te
    database: shared_dev

  staging:
    branch: release/*
    deploy: manual_trigger
    database: production_clone

  production:
    branch: main
    deploy: manual_onaylı
    database: production

Temel ders: Bu büyüklükte release’leri yöneten dedicated bir kişi gereklidir. Sorumluluk rotasyonu tutarsız release’lere yol açar çünkü farklı kişiler farklı standartlar uygular.

50+ Developer Takımları: Zorunlu Süreç Katmanı

200’den fazla geliştiriciyle çalışan büyük bir e-ticaret şirketi, large-scale Git yönetiminin gerçekte neye benzediğini göstermektedir:

Büyük takımlar hakkında acı gerçek:

• Takım-spesifik develop branch’lere ihtiyacın var
• Cherry-picking günlük aktivite haline geliyor
• Aynı anda birden fazla production versiyonu maintain edeceksin
• Feature flag’ler zorunlu oluyor (opsiyonel değil)

Ürün Tipi Her Şeyi Değiştirir

Takım büyüklüğü tek faktör değil; ürün tipin de branching kararlarını etkiler. Backend API, mobil uygulama ve kütüphane geliştirme farklı constraint’lere sahip ve her biri farklı strateji gerektirir.

Mobil Uygulamalar: Özel Kar Tanesi

Mobil development, backend odaklı branching stratejilerinin hesaba katmadığı kendine özgü kısıtlamalar içermektedir.

Mobil gerçeği:

Mobil neden farklı:

• App store review 1-7 gün sürüyor (rollback yapamazsın)
• Kullanıcılar hemen update etmiyor (birden fazla versiyon support ediyorsun)
• Hotfix’ler de review’dan geçmesi gerekebilir

Yaygın senaryo: Production’da kritik bir bug oluşur. Backend 30 dakikada fix eder ve deploy eder. Mobil için App Store review 3 gün sürer. Bu süre zarfında server-side workaround implement edilmesi gerekir. Mobil, sadece farklı kod değil; tamamen farklı bir release modeli demektir.

İşe yarayan mobil-spesifik strateji:

// Versiyon yönetimi yaklaşımı
const releases = {
  "3.0.0": "deprecated, zorunlu güncelleme",
  "3.1.0": "destekleniyor, opsiyonel güncelleme",
  "3.2.0": "güncel production",
  "3.3.0": "beta test'te",
  "3.4.0": "development'ta"
};

Backend Servisler: Microservices Labirenti

Microservices’ta branching stratejisi, servis dependency’lerini hesaba katmak zorundadır. 30’dan fazla servisi olan bir fintech şirketi bu sorunu şu yapıyla çözmüştür:

# Servis başına branching
service-payment/
├── main
├── develop
└── feature/*

service-auth/
├── main
├── develop
└── feature/*

# Ama işin püf noktası - integration testing
integration-tests/
├── main (tüm main branch'leri test eder)
├── develop (tüm develop branch'leri test eder)
└── scenario/black-friday-load

Yaygın dependency başarısızlık kalıbı:

• Service A (v2.0) Service B’ye (v1.5) bağlıdır
• Service B v2.0’a güncellenir, Service A’yı bozar
• Servisler yalnızca isolation’da test edildiği için production incident oluşur

İşe yarayan çözüm:

# Local testing için docker-compose.override.yml
services:
  payment:
    image: payment:${PAYMENT_VERSION:-develop}
  auth:
    image: auth:${AUTH_VERSION:-develop}
  inventory:
    image: inventory:${INVENTORY_VERSION:-develop}

# Developer'lar spesifik versiyon kombinasyonlarını test edebilir
# PAYMENT_VERSION=feature-new-flow AUTH_VERSION=main docker-compose up

Package/Library Development: Compatibility Dansı

Library development, farklı kısıtlamalar altında çalışır. Aynı anda birden fazla major versiyonu desteklemek temel zorluktur:

# Library branching stratejisi
main (v4.x development)
├── v3.x (LTS, sadece security fix'ler)
├── v2.x (sadece kritik fix'ler)
├── next (v5.0 experimental)
├── feature/new-component
└── fix/v3.x-security-patch

Sürdürülebilir versioning stratejisi:

{
  "releases": {
    "2.x": "2024-12'ye kadar sadece security fix",
    "3.x": "2025-06'ya kadar LTS",
    "4.x": "Güncel stable",
    "5.0-alpha": "Breaking change'ler, experimental"
  }
}

Kritik ders: Versiyonlar arası feature parity tutmaya çalışmak yaygın bir hatadır. Ekiplerin zamanının %70’i kimsenin talep etmediği feature’ları backport etmeye gider. Sürdürülebilir politika: yalnızca security fix ve kritik bug’ları backport etmek.

Environment Stratejisi: Dev/Staging/Prod’un Ötesindeki Gerçeklik

Küçük Takımlar: İki Environment Yeter

5 kişiden az takımlar için iki environment yeterlidir:

Her PR kendi preview environment’ını alıyor. Production main’i takip ediyor. Bu kadar.

Orta Takımlar: Klasik Üçlü

Standart dev/staging/production bu ölçekte işe yarar. Önemli olan her environment’ın nasıl kullanıldığıdır:

environments:
  development:
    amaç: "Integration testing, en yeni kod"
    data: "Sentetik test verisi"
    erişim: "Tüm developer'lar"
    reset: "Her gün sabah 3'te"

  staging:
    amaç: "Pre-production validation"
    data: "Production snapshot (anonimleştirilmiş)"
    erişim: "QA + Product + seçili dev'ler"
    reset: "Asla (production gibi davran)"

  production:
    amaç: "Müşteri yüzü"
    data: "Gerçek veri"
    erişim: "Sadece SRE takımı"

Yaygın hata: Staging’i oyun alanı olarak kullanmak. Staging “production-eksi-bir-gün” olarak ele alınmalıdır: production’da yapılmayacak bir şey staging’de de yapılmamalı.

Enterprise: Environment Patlaması

Enterprise ölçeğinde 12 farklı environment tipine ulaşmak yaygındır:

environments:
  # Development environment'ları
  dev1: "Backend takım integration"
  dev2: "Frontend takım integration"
  dev3: "Mobile takım integration"

  # Test environment'ları
  qa1: "Otomatik test"
  qa2: "Manuel test"
  uat: "Business user acceptance"

  # Performance environment'ları
  perf: "Performance testing (production-scale)"
  chaos: "Chaos engineering"

  # Pre-production
  staging: "Final validation"
  canary: "5% production traffic"

  # Production
  production-eu: "Avrupa müşteriler"
  production-us: "ABD müşteriler"

Gerçek: Bu environment’ların çoğu az kullanılır. Daha az ama daha iyi kullanılan environment, kapsamlı ama bakımsız bir listeden daha iyi sonuç verir.

Test Entegrasyonu: Test Gerçekte Nerede Yapılıyor?

Unit Test’ler: Tartışılmaz

# Bu build'ini fail etmeli, nokta
git push origin feature/my-feature
# Pre-push hook çalışıyor: npm test
# Test'ler fail ederse, push reddediliyor

Pratik bir kural: Unit test’ler 2 dakikadan uzun sürüyorsa, bunlar unit test değildir. 45 dakika süren “unit test”ler kılık değiştirmiş integration test’lerdir ve pipeline’ın farklı bir aşamasına ait olmalıdır.

Integration Testing: Branch İkilemi

Integration test’lerin nerede çalıştırılacağı konusunda yaygın başarısız yaklaşımlar:

1. Her feature branch’te - çok pahalı, çok yavaş
2. Sadece develop’ta - çok geç, herkesi bloklar
3. Sadece release branch’lerde - aşırı geç

İşe yarayan yaklaşım:

# .github/workflows/integration.yml
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  quick-integration:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - run: npm run test:integration:critical

  full-integration:
    if: contains(github.event.pull_request.labels.*.name, 'ready-for-review')
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - run: npm run test:integration:full

Her PR’da kritik test’ler, review için tag’lendiğinde full suite.

QA Testing: İnsan Unsuru

Küçük takımlar: Developer’lar kendi feature’larını staging’de test ediyor, sonra production.

Orta takımlar: Dedicated QA kişi/takım production’dan önce staging’de test ediyor.

Büyük takımlar: İşler burada karmaşıklaşıyor:

Yaygın başarısızlık kalıbı: QA bir feature’ı QA environment’ta onaylar; staging’de bozulur çünkü QA environment’ta farklı feature flag’ler etkindir. Çözüm: QA’nın production benzeri konfigürasyonla staging’de test etmesi.

Başarısızlık Kalıpları

Bu başarısızlık modelleri farklı organizasyonlarda tekrar eder. Bunları anlamak tekrarlanmalarını engeller.

Startup Ölçeğinde Git Flow

4 kişilik bir startup için full Git Flow implement edilir:

• Deployment sıklığı: Günlük’ten haftalık’a düşer
• Merge conflict’ler: %300 artar
• Takım morali: Dip yapar

Ders: Karmaşıklık takım büyüklüğü ve release temposuyla eşleşmelidir.

Büyüme Hızında Süreç Yok

Ekip 3 ayda 10’dan 40 developer’a büyür ve aynı “main’e commit at” yaklaşımı korunur:

• Bir haftada 3 production outage
• En büyük müşterinin kaybedilmesi
• Acil branching implementasyonu

Ders: Büyüme eşiklerini önceden öngörüp branching modelini güncellemek gerekir.

Environment Yayılması

30 kişilik takım için 15 farklı environment oluşturulur:

• AWS faturası: Yalnızca environment’lar için ayda $45.000
• Kullanım: Çoğu environment zamanın %10’undan az kullanılır
• Bakım: Yalnızca environment’lara adanmış 2 full-time DevOps mühendis

Ders: Daha fazla environment daha iyi kalite anlamına gelmez.

Strateji Önerileri

Bu kalıplardan türetilen somut bir karar çerçevesi:

Küçük Takımlar İçin (2-5 developer)

# Basit tut
main (production'a auto-deploy)
feature/* (preview environment'lar)
hotfix/* (gerekirse)

# Maksimum iki environment
preview (PR başına)
production

Orta Takımlar İçin (10-30 developer)

# Develop branch'li GitHub Flow
main (production)
develop (staging)
feature/* (develop'tan)
release/* (stabilizasyon gerekirse)

# Üç environment
development (continuous integration)
staging (pre-production)
production

Büyük Takımlar İçin (50+ developer)

# Takım branch'leriyle Modified Git Flow
main
develop
team/*/develop
feature/* (team develop'tan)
release/*
support/* (LTS için)

# Amaca göre environment
dev (integration)
qa (testing)
staging (pre-prod validation)
production (canary ile)

Mobil Takımlar İçin

Her zaman en az 3 versiyon maintain et:

• Güncel production
• Sonraki release (development/review’da)
• Hotfix branch (acil durumlar için)

Microservices İçin

• Servis başına bağımsız branching
• Major feature’lar için koordine release branch’ler
• Integrated environment’lar yerine contract testing

Evrensel Gerçekler

1. Basit başla, sadece canın yandığında karmaşıklık ekle
2. Branching stratejin deployment sıklığınla eşleşmeli
3. Daha fazla branch = daha fazla merge conflict = daha yavaş delivery
4. Environment’lar para ve zaman maliyeti - minimum viable sayı kullan
5. Yapabildiğin her şeyi otomatikleştir, özellikle acı veren kısımları

Son Düşünceler

En iyi branching stratejisi, takımın gerçekten takip ettiği stratejidir. Basit stratejilerin tutarlı uygulanması, karmaşık stratejilerin tutarsız uygulanmasından sürekli olarak daha iyi sonuç verir.

Strateji Karşılaştırması: Gerçeklik Kontrolü

Bu stratejilerin farklı takımlarda üretim sonuçlarına dayanan dürüst değerlendirmesi:

Her Strateji Hakkında Gerçek

Strateji	En İyi	En Kötü	Overhead	Öğrenme Eğrisi
Trunk-Based	Küçük, güvenilir takımlar	Büyük, dağıtık takımlar	Çok Düşük	Orta
GitHub Flow	Çoğu takım	Karmaşık compliance	Düşük	Kolay
Tag-Based Release	QA-gated release’ler	Continuous deployment	Orta	Kolay
GitLab Flow	Environment karmaşıklığı	Basit uygulamalar	Orta	Orta
Git Flow	Enterprise, compliance	Startup’lar, hız	Yüksek	Zor

Performans Referans Verisi

Gözlemlenen üretim sonuçları, strateji ve takım büyüklüğüne göre:

• Trunk-Based (4 kişilik takım): Günde 15 deploy, 0.1% başarısız deployment, 2 saatlik feature cycle
• GitHub Flow (15 kişilik takım): Günde 5 deploy, 0.5% başarısız deployment, 1 günlük feature cycle
• Tag-Based Release (25 kişilik takım): Günde 3 deploy, 0.2% başarısız deployment, 2 günlük feature cycle
• GitLab Flow (30 kişilik takım): Günde 2 deploy, 0.3% başarısız deployment, 3 günlük feature cycle
• Git Flow (200 kişilik takım): Haftada 1 deploy, 0.1% başarısız deployment, 2 haftalık feature cycle

Takımların %80’i GitHub Flow kullanmalı. Git stratejilerinin Toyota Camry’si: güvenilir, basit, çoğu durumda işe yarıyor.

Git Flow’u sadece şu durumlarda kullan: Compliance zorunluluğu var ya da 100+ developer’ın var.

Trunk-Based’i sadece şu durumlarda kullan: Takımın Netflix seviyesinde engineering olgunluğa sahip.

Tag-Based Release Flow şunun için: QA onay gate’leri olan programlı release’ler isteyen takımlar.

GitLab Flow şunun için: GitHub Flow yeterli değil ama Git Flow çok fazla.

Başka organizasyonlar için işe yarayanı körü körüne kopyalamak yerine, basit başlamak ve gerçek pain point’ler ortaya çıktıkça evrimleştirmek daha sağlıklı bir yoldur.

Git bir araçtır, doktrin değil. Amaç “mükemmel” branching modeline sahip olmak değil, kaliteli yazılımı sürdürülebilir bir hızda geliştirmektir.

Strateji Seçici

Gerçek dünya kısıtlamalarına göre hangi stratejiyi seçmek gerektiğini gösteren karar çerçevesi:

Özet: Gerçekte Ne İşe Yarıyor

Takımların %80’i GitHub Flow kullanmalıdır. Git stratejilerinin Toyota Camry’si: güvenilir, basit, işini görür.

Trunk-Based Development’ı yalnızca şu durumda kullan: Takım, Netflix seviyesinde engineering disiplini ve test coverage’ına sahip.

Git Flow’u yalnızca şu durumda kullan: Compliance zorunluluğu var ya da 100’den fazla developer yönetiliyor.

Tag-Based Release Flow: QA onay gate’leri ve programlı release’ler gerektiren takımlar için.

GitLab Flow: GitHub Flow yeterli olmadığı ama Git Flow’un fazla olduğu durumlar için.

Sonraki Adımlar

1. Mevcut pain point’leri değerlendir: Yavaş deploy mu, merge conflict mi, bug kaçırma mı?
2. En büyük problemi çözen en basit stratejiyi seç
3. Incremental implement et: Her şeyi bir anda değiştirme
4. Etkiyi ölç: Deployment frequency, failure rate ve takım memnuniyeti
5. Büyüdükçe evrimleştir: 5 developer’da işe yarayan 50’de işe yaramaz

Git bir araçtır, doktrin değil. Amaç “mükemmel” branching modeline sahip olmak değil, kaliteli yazılımı sürdürülebilir bir hızda geliştirmektir.

Kaynaklar

• Kaynak Kodu Dallarını Yönetme Örüntüleri - Martin Fowler - Entegrasyon sıklığını, özellik bayraklarını ve kısa ömürlü dallar lehine argümanları kapsayan kapsamlı branching pattern katalogu
• Trunk Tabanlı Geliştirme - Tek bir trunk dalına sık commit yapma pratiğini, kısa ömürlü özellik dalları ve sürüm stratejileri hakkında kılavuzla belgeleyen referans sitesi
• Git Workflow Karşılaştırması - Atlassian - Ödünleşim analiziyle merkezi, özellik dalı, Gitflow ve fork workflow’larının pratik karşılaştırması
• GitHub Flow - GitHub Docs - Sürekli teslimat için tasarlanmış GitHub’ın hafif dal ve pull request workflow’unun resmi açıklaması
• Git - Referans Dokümantasyonu - Dal yönetimi komutları ve kavramları için yetkili kaynak olan resmi Git komut referansı ve kullanıcı kılavuzu