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-spesifik önerilerine geçmeden önce, ana stratejileri ve ne zaman gerçekten işe yaradıklarını (ya da muhteşem şekilde başarısız olduklarını) anlayalım. Her stratejinin güçlü ve zayıf yönleri var; doğru seçim takımın büyüklüğüne, ürün tipine ve deployment kültürüne bağlı.

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

Gerçek hikaye: Bir startup’ta 4 developer’la trunk-based development kullandık. Günde 15 deploy ettik, sıfır merge conflict yaşadık ve inanılmaz hızlı hareket ettik. Rakiplerimiz hala haftalık release yaparken biz günlük birden fazla feature ship ediyorduk.

Ne zaman felaket:

• Koordinasyonsuz büyük takımlar
• Kötü test coverage
• Karmaşık release süreçleri
• Düzgün eğitim almamış junior developer’lar

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

Savaş hikayesi: 40 developer’la trunk-based denedik. Tam kaos. Main branch her gün bozuluyordu, developer’lar commit atmaktan korkuyor, productivity çakıldı. Gecede Git Flow implement etmek zorunda kaldık.

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

Kişisel deneyim: 200 kişilik takımda Git Flow implement ettim. İşe yaradı ama overhead müthişti. Developer zamanının 30%‘u branch management’ta geçiyordu. Kalite için iyi, hız için berbat. Büyük takımlarda kalite kritikse bu trade-off 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ü

Gerçek örnek: 15 developer’lı SaaS şirketinde GitHub Flow kullandık. Sweet spot - kalite için yeterli process, fazla overhead yok. Günde 3-5 deploy ettik. 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)

Gerçek hikaye: 25 developer’lı fintech şirketinde implement ettim. Deployment hatalarını 80% azalttı, QA memnuniyeti dramatically arttı çünkü hangi versiyonu test ettiklerini her zaman biliyorlardı. Rollback’ler 45 dakikalık panik seanslarından 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ı: Simple Tut, Aptal

Küçük bir fintech startup’ta çalışırken tam olarak 3 developer’dık. İşte gerçekten işe yarayan:

Bu kadar. Develop branch yok, release branch’ler yok, karmaşık flow yok. Neden? Çünkü 3 kişiyle muhtemelen aynı odadasın (veya Slack kanalında). Herkesin ne üzerinde çalıştığını tam olarak biliyorsun.

Ne yaptık:

• 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ıştı:

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

Kaçınman gereken kritik hata: Burada Git Flow implement etme. 4 developer’lık takım için 7 farklı branch tipi olan takımlar gördüm. Merge etmek o kadar karmaşıktı ki 2 haftada bir deploy ediyorlardı. Küçük takımlar için basitlik her zaman öncelik olmalı; karmaşıklık sadece gerçekten ihtiyaç duyulduğunda eklenmeli. Hangi stratejiyi seçersen seç, takımının günlük rutinine uyduğundan emin ol.

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

İşler burada ilginçleşiyor. Bu büyüklükte artık her şeyi kafanda tutamazsın. Bunu bir SaaS şirketinde zor yoldan öğrendim.

Kritik eklemeler:

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

Gerçekten işe yarayan environment setup:

# Environment mapping'imiz
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

Zor yoldan öğrenilen ders: Bu büyüklükte release’leri yöneten dedicated bir insan lazım. Bu sorumluluğu rotate etmeyi denedik - felaket. Farklı insanların farklı standartları vardı, tutarsız release’lerle sonuçlandık.

50+ Developer Takımları: Process Cehennemi’ne Hoşgeldin (Ama Gerekli Cehennem)

200+ developer’lı büyük bir e-ticaret şirketine katıldığımda Git bildiğimi sanıyordum. Yanılmışım. İşte large-scale’in gerçekte neye benzediği:

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’ın çoğu backend developer’ın takdir etmediği unique constraint’leri var. Bunu backend’den React Native development’a geçerken öğrendim.

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

Gerçek hikaye: Bir seferinde production’da kritik bug vardı. Backend’de 30 dakikada fix edip deploy ettik. Mobil fix? App Store review’dan geçmesi 3 gün sürdü. Beklerken server-side workaround implement etmek zorunda kaldık.

İş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’la branching stratejin servis dependency’lerini hesaba katmalı. 30+ servisi olan bir fintech şirketinde implement ettiğimiz:

# 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

Yaşadığımız dependency kabusı:

• Service A (v2.0) Service B’ye (v1.5) bağlı
• Service B v2.0’a update oluyor, Service A’yı bozuyor
• Production incident çünkü servisleri sadece isolation’da test ettik

Gerçekten iş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 tamamen farklı bir canavar. Open-source React component library maintain ederken, aynı anda birden fazla major versiyon support etmemiz gerekiyordu:

# 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

Bizi kurtaran 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 maintain etmeyi denedik. Büyük hata. Zamanımızın 70%‘ini kimsenin istemediği feature’ları backport etmekle geçirdik. Şimdi sadece security fix ve kritik bug’ları backport ediyoruz.

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

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

5 kişiden az takımlar için gerçek şu: 5 environment’a ihtiyacın yok. Biz sadece ikiyle çalıştık:

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

Orta Takımlar: Klasik Üçlü

Standart dev/staging/production çalışıyor, ama biz gerçekte böyle kullandık:

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ı"

Herkesin yaptığı hata: Staging’i oyun alanı olarak kullanmak. Staging’i “production-eksi-bir-gün” olarak görmeyi öğrendik. Production’da yapmazdıysan, staging’de de yapma.

Enterprise: Environment Patlaması

Enterprise seviyesinde 12 farklı environment tipimiz vardı:

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ıyordu. Yeniden yapsam, daha az ama daha iyi kullanılan environment için daha çok savaşırdım.

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

Controversial görüşüm: Unit test’lerin 2 dakikadan uzun sürüyorsa, onlar unit test değil. 45 dakika süren “unit test”lerimiz vardı. Kılık değiştirmiş integration test’lerdi.

Integration Testing: Branch İkilemi

İşler burada karışıyor. Integration test’leri nerede çalıştırırsın?

Deneyip başarısız olduklarımız:

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

Gerçekten işe yarayan:

# .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:

Gerçek hikaye: QA bir feature’ı QA environment’ta onaylamıştı. Staging’de bozuldu çünkü QA environment farklı feature flag’leri açıktı. Artık QA production-benzeri konfigürasyonla staging environment’ta test ediyor.

Gerçek Dünya Başarısızlıkları ve Dersler

”Startup’ta Git Flow” Felaketi (2017)

4 kişilik startup için full Git Flow implement ettik. Sonuçlar:

• Deployment sıklığı: Günlük’ten haftalık’a
• Merge conflict’ler: 300% arttı
• Takım morali: Dip yaptı

Ders: Karmaşıklık takım büyüklüğü ve ihtiyaçlarla eşleşmeli.

”Scale-up’ta Process Yok” Faciası (2019)

3 ayda 10’dan 40 developer’a scale ettik, aynı “main’e commit at” yaklaşımını koruduk:

• Bir haftada 3 production outage
• En büyük müşteriyi kaybettik
• Acil proper branching implementasyonu

Ders: Büyümeyi öngör ve canın yanmadan önce ayarla.

”Environment Yayılması” Para Çukuru (2021)

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

• AWS faturası: Sadece environment’lar için ayda $45,000
• Kullanım: Çoğu environment zamanın 10%‘undan az kullanılıyor
• Bakım: Sadece environment’lar için 2 full-time DevOps mühendis

Ders: Daha fazla environment ≠ daha iyi kalite.

Benim Taraflı Önerilerim

Tüm bu yıllar ve başarısızlıklardan sonra, gerçekten önerdiğim:

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ın gerçekten takip ettiği stratejidir. Basit stratejilerin iyi execute edilmesinin, karmaşık stratejilerin kötü execute edilmesinden her zaman daha iyi performans gösterdiğini gördüm.

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

Tüm bu stratejileri farklı takımlarda implement ettikten sonra, dürüst değerlendirmem:

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

Gerçek Performans Verisi

Çalıştığım takımlardan:

• 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

Çoğu takım GitHub Flow kullanmalı. Git stratejilerinin Toyota Camry’si - güvenilir, basit, durumların 80%‘inde 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şkaları için işe yarayanı körü körüne kopyalama. Basit başla, pain point’leri ölç ve teorik best practice’ler değil, gerçek ihtiyaçlara göre evrimleş.

Ve unutma: Git bir araç, din değil. Amaç perfect branching model’e sahip olmak değil, kaliteli yazılım ship etmek.

Strateji Seçici: Senin Maceran

Tahmin yapmayı bırak. Gerçek dünya kısıtlamalarına göre tam olarak hangi stratejiyi kullanman gerektiği burada:

Alt Çizgi: Gerçekte Ne İşe Yarıyor

Farklı takım büyüklükleri ve endüstrilerde sayısız implementasyondan sonra, controversial görüşüm şu:

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

Trunk-Based Development’ı sadece şu durumda kullan: Takımında Netflix seviyesinde engineering disiplini ve test coverage’ı var.

Git Flow’u sadece şu durumda kullan: Compliance tarafından yasal olarak zorunlu ya da 100+ developer yönetiyorsun.

Tag-Based Release Flow’u şu durumda kullan: QA onay gate’leri ve programlı release’lere ihtiyacın var.

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

Sonraki Adımların

1. Mevcut pain point’lerini değerlendir - Deploy etmekte yavaş mısın? Merge conflict’lerin var mı? Bug’ları kaçırıyor musun?
2. En büyük problemini çözen en basit stratejiyi seç
3. Incremental olarak implement et - Her şeyi bir anda değiştirme
4. Etkisini ölç - Deployment frequency, failure rate ve takım memnuniyetini takip et
5. Scale ederken evolve et - 5 developer’da işe yarayan şey 50’de işe yaramaz

Unutma: Git bir araç, din değil. Amaç “mükemmel” branching modeline sahip olmak değil, kaliteli yazılımı hızlı ship etmek.

Basit başla. Acıyı ölç. Teoriye değil gerçekliğe göre evolve et.